You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Joe Bohn <jo...@earthlink.net> on 2006/02/01 16:38:56 UTC
Geronimo dependency issues
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
Re: Geronimo dependency issues
Posted by Joe Bohn <jo...@earthlink.net>.
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
Re: Geronimo dependency issues
Posted by David Jencks <da...@yahoo.com>.
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
Re: Geronimo dependency issues
Posted by Joe Bohn <jo...@earthlink.net>.
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
Re: Geronimo dependency issues
Posted by David Jencks <da...@yahoo.com>.
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
Re: Geronimo dependency issues
Posted by Joe Bohn <jo...@earthlink.net>.
Thanks for the response Dain. Please see the additional details I
included in my response to David. I think you may be right that the
GBean deployer service is using the wrong classloader. Please let me
know if the additional details my other response help narrow things down
further.
Joe
Dain Sundstrom wrote:
> I think there is a code problem here. The geronimo-gbean-deployer
> should not need to see TranQL or the transaction manager. It should
> only need to see the classes required to process the xml and create the
> GBeanData objects. I think there are few possible problems here:
>
> 1) The geronimo-gbean-deployer is seeing too many classes - For
> example, if the geronimo-gbean-deployer is seeing the TranQL classes,
> it must also be able to see all of the dependencies of TranQL which is
> my you need to add JTA. I think is where you currently are and suggest
> you back out adding the extra dependencies to the geronimo-
> gbean-deployer plan.
>
> 2) The GBean deployer service is using the wrong class loader to try to
> load the gbean service class (the class of the declared gbean service
> in the xml file). This should be fairly easy to check by droping a
> break point in the deployer and inspecting the class loader it is using.
>
> 3) The class you are loading could have unnecessary coupling which
> requires to many classes to be visible to the target class loader.
>
> -dain
>
> 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.
>>
>> 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.
>>
>> 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
Re: Geronimo dependency issues
Posted by Dain Sundstrom <da...@iq80.com>.
I think there is a code problem here. The geronimo-gbean-deployer
should not need to see TranQL or the transaction manager. It should
only need to see the classes required to process the xml and create
the GBeanData objects. I think there are few possible problems here:
1) The geronimo-gbean-deployer is seeing too many classes - For
example, if the geronimo-gbean-deployer is seeing the TranQL classes,
it must also be able to see all of the dependencies of TranQL which
is my you need to add JTA. I think is where you currently are and
suggest you back out adding the extra dependencies to the geronimo-
gbean-deployer plan.
2) The GBean deployer service is using the wrong class loader to try
to load the gbean service class (the class of the declared gbean
service in the xml file). This should be fairly easy to check by
droping a break point in the deployer and inspecting the class loader
it is using.
3) The class you are loading could have unnecessary coupling which
requires to many classes to be visible to the target class loader.
-dain
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.
>
> 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.
>
> 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
Re: Geronimo dependency issues
Posted by Joe Bohn <jo...@earthlink.net>.
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.
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.
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