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
