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
