geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Geronimo dependency issues
Date Sun, 05 Feb 2006 03:34:18 GMT
David Jencks wrote:
> 
> On Feb 4, 2006, at 8:31 AM, Joe Bohn wrote:
> 
>> Here's an update on where I'm at with this and to see if anybody  has 
>> any other ideas (thanks for the help I've already received from  David 
>> Jencks and Matt).
>>
>> The classloader problem appears to be coming from the jetty  
>> deployment of daytrader during the configs build.  By trial and  error 
>> I discovered that this appears to have nothing to do with  OpenEJB or 
>> OpenEJB-deployer as we once thought but rather jetty- deployer.
> 
> 
> Can you explain your reasoning?  The stack trace looks like it is  
> coming out of the openejb builder.

I may be mistaken, but I was basing this assumption on the following:

1) Running the daytrader config build produced these messages that led 
me to believe the parent was geronimo-gbean-deployer:
681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState  - 
GBeanInstanceState for: 
geronimo.maven:J2EEApplication=null,J2EEModule=geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car,J2EESe
rver=geronimo,j2eeType=Deployer,name=Deployer State changed from stopped 
to starting
681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState  - 
Checking if parent is running: 
parent=geronimo.config:name="geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car"
681 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState  - 
Parent is running: 
parent=geronimo.config:name="geronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car"
Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'.
Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
17856 [main] ERROR org.apache.geronimo.deployment.Deployer  - Deployment 
failed due to
java.lang.NoClassDefFoundError: org/tranql/ejb/EJBProxyFactory
         at java.lang.ClassLoader.defineClass0(Native Method)

2) config openejb-deployer already had a geronimo.dependency on tranql.

3) Adding a tranql dep. to openejb-builder didn't change the result.

3) Adding a tranql dep. to the config openejb didn't change the result.

4) Adding a tranql dep. to geronimo-gbean-deployer did change the result.

> 
>>
>> Here's a graph of the jetty-deployer parent dependencies (I  followed 
>> Matt's lead on creating text diagrams :-) ).
>>
>> geronimo-gbean-deployer             j2ee-server
>>          A                              A
>>          |           parent             |
>>          |------------------------------|
>>          |
>> j2ee-deployer             jetty
>>      A                      A
>>      |      parent          |
>>      |----------------------|
>>      |
>> jetty-deployer
>>
>> Debug messages seem to indicate that the classloader in question is  
>> the geroniom-gbean-deployer class loader and I have had some  marginal 
>> success (ie. changing the problem) by including  dependencies in this 
>> config.  However, I can't quite make sense of it.
> 
> 
> As dain mentioned, including more in the geronimo-gbean-deployer  
> classpath is definitely the wrong approach.  I believe you need to  
> figure out why that classloader is being used rather than the openejb  
> config classloader which is the one that should contain the tranql  
> classes.
> 
> It is possible that we need to supply a classloader such as the  
> openejb-builder classloader to the proxy construction code.  I would  
> start by double checking that the openejb config classloader actually  
> has the tranql classes in it and that the openejb-builder config  
> classloader can therefore load them.

Openejb config does not contain a geronimo.dependency on tranql and 
adding one doesn't seem to make a difference to the initial failure in 
daytrader jetty config.   Also, openejb-builder doesn't have a 
dependency on openejb config.  The openejb-deployer config does have a 
dependency (import) on openejb.  However, this doesn't seem to help us 
get the tranql classes in the classloader (even when I added it as a 
geronimo.dependency).

I guess I'll have to get maven working in eclipse so that I can better 
inspect the classloaders and determine the cause of the failure.  Thanks 
for the tips and please let me know if this additional information helps 
explain things better.

Joe

> 
> thanks
> david jencks
> 
>>
>> geronimo-gbean-deployer never had a dependency to rmi-naming to  begin 
>> with.   On the other hand, both the jetty config and the j2ee- server 
>> config do have a dependency to rmi-naming.  So I would have  thought 
>> that adding the tranql dependency here would improve  things.  But it 
>> had no effect at all.  However, it changes the  problem if I add the 
>> tranql dependency to geronimo-gbean-deployer.   I then get this error:
>>
>> 26979 [main] ERROR org.apache.geronimo.deployment.Deployer  -  
>> Deployment failed due to
>> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>>
>> With Matt's help I found this class in the jta spec and added a  
>> dependency for that as well to geronimo-gbean-deployer which then  
>> resulted in this error:
>>
>> 14371 [main] ERROR org.apache.geronimo.deployment.Deployer  -  
>> Deployment failed due to
>> java.lang.LinkageError: loader constraints violated when linking  
>> javax/transaction/UserTransaction class
>>
>> I'm not even sure exactly what a LinkageError is .... but I wonder  if 
>> I'm just chasing my tail anyway.  Having the dependency on  tranql et. 
>> al. in geroniom-gbean-deployer might not be any better  than having it 
>> in rmi-naming (still seems misplaced).
>>
>> Any hints/suggestions are welcome.
>>
>> BTW, out of about 22 questionable jars included in the minimal  tomcat 
>> assembly I was able to remove 19 of them with the minimal  assembly 
>> still functioning.  Of course, I can only make these  changes for that 
>> assembly if I can get around these side-effect  problems in other 
>> configurations and assemblies.
>>
>> Joe
>>
>>
>> Joe Bohn wrote:
>>
>>> I'm looking to eliminate some of the unnecessary dependencies  
>>> defined in our modules and configurations so that we can build  
>>> smaller assemblies.
>>> While investigating what would be necessary to remove the tranql  jar 
>>> from the minimal assembly I removed a dependency to tranql in  the 
>>> rmi-naming configuration.
>>> I expected some problems, but the result I received is a bit  
>>> strange.  I get the NoClassDefFoundError listed below when  deploying 
>>> (as part of the build) the configuration for Daytrader.   Is this 
>>> expected based upon removing the tranql dependency from  rmi-naming 
>>> or is there something strange going on with the  classloaders?
>>> +----------------------------------------
>>> | configurations Daytrader using derby deployed on jetty
>>> | Memory: 52M/63M
>>> +----------------------------------------
>>> DEPRECATED: the default goal should be specified in the <build>  
>>> section of project.xml instead of maven.xml
>>> DEPRECATED: the default goal should be specified in the <build>  
>>> section of project.xml instead of maven.xml
>>> build:end:
>>> You are working offline so the build will continue, but geronimo- 
>>> daytrader-derby-db-1.1-SNAPSHOT.jar may be out of date!
>>> You are working offline so the build will continue, but daytrader- 
>>> ear-1.1-SNAPSHOT.ear may be out of date!
>>> build:start:
>>> multiproject:install-callback:
>>>     [echo] Running car:install for Daytrader using derby deployed  on 
>>> jetty
>>> Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
>>> Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'.
>>> Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
>>> 143877 [main] ERROR org.apache.geronimo.deployment.Deployer  -  
>>> Deployment failed due to
>>> java.lang.NoClassDefFoundError: org/tranql/ejb/EJBProxyFactory
>>>         at java.lang.ClassLoader.defineClass0(Native Method)
>>>         at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
>>>         at java.security.SecureClassLoader.defineClass 
>>> (SecureClassLoader.java:123)
>>>         at java.net.URLClassLoader.defineClass(URLClassLoader.java: 251)
>>>         at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
>>>         at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
>>>         at java.security.AccessController.doPrivileged(Native Method)
>>>         at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
>>>         at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
>>>         at  
>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass 
>>> (MultiParentClassLoader.java:209)         at  
>>> java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>>>         at  
>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass 
>>> (MultiParentClassLoader.java:201)         at  
>>> java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>>>         at  
>>> org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass 
>>> (MultiParentClassLoader.java:201)         at  
>>> java.lang.ClassLoader.loadClass(ClassLoader.java:235)
>>>         at java.lang.ClassLoader.loadClassInternal 
>>> (ClassLoader.java:302)
>>>         at  
>>> org.openejb.deployment.OpenEJBModuleBuilder.createEJBProxyFactory 
>>> (OpenEJBModuleBuilder.java:579)         at  
>>> org.openejb.deployment.CMPEntityBuilder$1.buildEJBProxyFactory 
>>> (CMPEntityBuilder.java:125)         at  
>>> org.openejb.deployment.SchemataBuilder.processEnterpriseBeans 
>>> (SchemataBuilder.java:306) ...
>>> Thanks,
>>> Joe
>>> ---
>>> Joe Bohn
>>> joe.bohn at earthlink.net
>>> "He is no fool who gives what he cannot keep, to gain what he  cannot 
>>> lose."   -- Jim Elliot
>>
>>
>> -- 
>> Joe Bohn
>> joe.bohn at earthlink.net
>>
>> "He is no fool who gives what he cannot keep, to gain what he  cannot 
>> lose."   -- Jim Elliot
> 
> 
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message