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 Mon, 06 Feb 2006 21:40:17 GMT


I'm not sure what that problem really is/was.   I wanted to pick up your 
latest changes to see what was different.  For some reason I can no 
longer build my older image (pre-movement of openejb) after picking up a 
new image for both G and openejb.  It almost seems like my old image of 
openejb had been updated somehow for a new tranql build ... but the 
tranql that the build was referencing didn't match what openejb required 
(I was getting a compile error on a missing method/symbol 
org.tranql.cache.GlobalSchema.populateGlobalSchema).  With the movement 
of OpenEJB I couldn't figure out how to refresh my old OpenEJB image again.

I do have a diff file .. but it isn't very helpful.  The only obvious 
difference was that you only removed the geronimo dependency in tranql 
while I removed the entire maven dependency on tranql from config 
rmi-naming.  However, when I made the same change with the new G image 
things still seem to work just fine and I don't get the failures I 
received earlier with the old build.

It doesn't seem like it's worth trying to get my old build back to where 
it was failing (if I even could) to figure out the problem that only I 
was hitting :-)  ... so I'm moving forward with the new image new.

Thanks for your help.

Joe


David Jencks wrote:
> I could not reproduce this problem.  I tried moving openejb, tranql,  
> and activemq dependencies to more appropriate places and after some  
> fiddling it seems to work, so I committed my changes (geronimo  r375137, 
> openejb r2428 ).  In the future including diffs of your  changes might 
> help figure out exactly where you are stuck.
> 
> thanks
> david jencks
> 
> On Feb 4, 2006, at 7:34 PM, Joe Bohn wrote:
> 
>> 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
> 
> 
> 
> 

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