geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo dependency issues
Date Sat, 04 Feb 2006 21:17:01 GMT

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.
>
> 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.

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


Mime
View raw message