Re: embedded tomcat (8.0.39) shared jars
I've examined the issue more closely. The class (interface) is loaded twice, once by WebappClassLoader and once by Launcher$AppClassLoader, both from StandardContext.listenerStart() line: 4853 The WebappClassLoader one is reached via regular method calls, the other through reflection: MapperRegistry.getMapper(Class, SqlSession) line: 40 Configuration.getMapper(Class, SqlSession) line: 639 SqlSessionManager.getMapper(Class) line: 215 MyBatisDbSessionManager.getMapper(Class) line: 84 ProcessTasksService(BasisRestService).initializeAfterBootstrap() line: 57 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 Delegate.invoke(Object, Object[]) line: 88 BootstrapCompleteSignal(SynchronousSignal).callHandler(SignalHandler, T) line: 22 BootstrapCompleteSignal(Signal).invokeSignalHandlers(T) line: 109 BootstrapCompleteSignal(Signal).raise(T) line: 131 BootstrapCompleteSignal(Signal).raise() line: 93 AnubIsContainer.bootstrap(String) line: 230 AnubIsContainer.bootstrap() line: 156 MySystemPropertiesHelper.contextInitialized(ServletContextEvent) line: 14 StandardContext.listenerStart() line: 4853 StandardContext.startInternal() line: 5314 StandardContext(LifecycleBase).start() line: 145 ContainerBase$StartChild.call() line: 1408 ContainerBase$StartChild.call() line: 1398 FutureTask.run() line: 266 ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 ThreadPoolExecutor$Worker.run() line: 617 Thread.run() line: 745 Does the reflection cause the other classloader to be used? Tom On 21-1-2017 09:43, Tom Eugelink wrote: I'm very close at getting the embedded Tomcat running from an Eclipse Maven project; the (hopefully final) issue I'm now facing is the fact that a class is being loaded by the WebappClassloader and in another execution path via the launcher classloader, which makes them two different classes and things go awry. Tomcat of course is being started by Eclipse with a full classpath, and I 'forward' that classpath to the webapp. If I do not do that, the webapp won't find anything that is on that startup classpath, so apparently Tomcat's classloading setup completely ignores the initial classpath and replaces it with its own structure. Ok, but somehow they do get mixed up, otherwise I would not run into the situation described above. So I was thinking that I could try and figure out why one class is being loaded by the launcher, but I foresee a long and windy path, with a lot of different situations where this loading goes wrong. So instead of trying to solve the conflict at webapp level, I could move in another direction: in normal (non embedded) Tomcat installations you are allowed to put shared jars in Tomcat's lib folder. These are then accessible by all webapps. Is it possible to have embedded Tomcat make its classpath available to the webapps, or configure the classes-directories and jars resources at Tomcat level? Tom - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
embedded tomcat shared jars
I'm very close at getting the embedded Tomcat running from an Eclipse Maven project; the (hopefully final) issue I'm now facing is the fact that a class is being loaded by the WebappClassloader and in another execution path via the launcher classloader, which makes them two different classes and things go awry. Tomcat of course is being started by Eclipse with a full classpath, and I 'forward' that classpath to the webapp. If I do not do that, the webapp won't find anything that is on that startup classpath, so apparently Tomcat's classloading setup completely ignores the initial classpath and replaces it with its own structure. Ok, but somehow they do get mixed up, otherwise I would not run into the situation described above. So I was thinking that I could try and figure out why one class is being loaded by the launcher, but I foresee a long and windy path, with a lot of different situations where this loading goes wrong. So instead of trying to solve the conflict at webapp level, I could move in another direction: in normal (non embedded) Tomcat installations you are allowed to put shared jars in Tomcat's lib folder. These are then accessible by all webapps. Is it possible to have embedded Tomcat make its classpath available to the webapps, or configure the classes-directories and jars resources at Tomcat level? Tom - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared jars
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 9/12/2009 7:44 PM, Tim Berglund wrote: Still stuck, and not sure where to look. Mad grateful for further ideas. Looks like grails/groovy is trying to create a new object. Is that being done from within a JAR in the shared ClassLoader or from within your webapp's ClassLoader? Presumably, you took a set of JARs required for a single webapp and split them into shared and private JARs. Which ones went where? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkquUrUACgkQ9CaO5/Lv0PAqrQCcCFKAdxIMEsKJxLsAHJmrFTXI TQYAnjmGoRVP3Yb6XvjdU91f1b8dDisM =Kr2z -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared jars
2009/9/14 Tim Berglund tlbergl...@gmail.com My intention was to put framework JARs in shared/lib, and plugin and application JARs in WEB-INF/lib. That's a good way to split them up for deployment reasons, but it now seems like it just won't work ClassLoader-wise. Looks that way. Modern frameworks make many assumptions about the classloader structure in order to do what thay do, and those assumptions do not necessarily hold in a servlet container. Is now the time to give up? :) Yes. - Peter
Re: Shared jars
Christopher, A class in the WEB-INF/classes directory (to wit, HibernateGrailsPlugin.class) is trying to create an object that implements an interface (org.hibernate.SessionFactory) found in a JAR in WEB-INF/lib (hibernate3-3.1.1.jar). However, it's doing this through no small amount of Grails-sponsored Groovy metaprogramming, which means that the actual Java class doing the instantiating is internal to Groovy itself. The Groovy JAR is, of course, in shared/lib. All of which means that yes, something in shared/lib wants to load something in WEB-INF/lib. And now that you mention it, it seems fair not to expect classes from the shared ClassLoader to see classes from the webapp ClassLoader. My intention was to put framework JARs in shared/lib, and plugin and application JARs in WEB-INF/lib. That's a good way to split them up for deployment reasons, but it now seems like it just won't work ClassLoader-wise. Is now the time to give up? :) Tim That's exactly right: a class in a JAR in the webapp ClassLoader (to wit, is trying to create an object that implements an interface On Mon, Sep 14, 2009 at 8:27 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 9/12/2009 7:44 PM, Tim Berglund wrote: Still stuck, and not sure where to look. Mad grateful for further ideas. Looks like grails/groovy is trying to create a new object. Is that being done from within a JAR in the shared ClassLoader or from within your webapp's ClassLoader? Presumably, you took a set of JARs required for a single webapp and split them into shared and private JARs. Which ones went where? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkquUrUACgkQ9CaO5/Lv0PAqrQCcCFKAdxIMEsKJxLsAHJmrFTXI TQYAnjmGoRVP3Yb6XvjdU91f1b8dDisM =Kr2z -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared jars
Then the Grails WAR shall be enormous now and always. So let it be written, so let it be done. :) Thanks for your help thinking through this. I don't mind quitting now that I understand what the problem is. Tim On Mon, Sep 14, 2009 at 8:48 AM, Peter Crowther peter.crowt...@melandra.com wrote: 2009/9/14 Tim Berglund tlbergl...@gmail.com My intention was to put framework JARs in shared/lib, and plugin and application JARs in WEB-INF/lib. That's a good way to split them up for deployment reasons, but it now seems like it just won't work ClassLoader-wise. Looks that way. Modern frameworks make many assumptions about the classloader structure in order to do what thay do, and those assumptions do not necessarily hold in a servlet container. Is now the time to give up? :) Yes. - Peter
Re: Shared jars
Good idea. I searched all jars in lib, shared/lib, and webapps/AppName/WEB-INF/lib. org.hibernate.SessionFactory occurs in one file only, which is hibernate3-3.3.1.jar. I don't know if this is the first class in the WEB-INF/lib folder to be loaded, but it's not out of the question that it is. It's like Tomcat isn't looking there if I tell it the shared classloader should be looking in shared/lib. Like I described before, it works if I point the shared classloader at the WEB-INF/lib directory as well (which was a test, and not a proposed solution :) ), which is telling. Still stuck, and not sure where to look. Mad grateful for further ideas. Tim 2009/9/11 Caldarale, Charles R chuck.caldar...@unisys.com From: Tim Berglund [mailto:tlbergl...@gmail.com] Subject: Re: Shared jars The class failing to load is org.hibernate.SessionFactory Any chance the above class is in more than one place in this branch of the classloader tree? An NCDFE can result from that condition as well as the class simply not being there (or accessible). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared jars
Tim Berglund wrote:
I'm trying to enable the shared classloader on Tomcat 6.0.20 (Java 1.6.0_15
on Mac OSX 10.6). I've put this line in conf/catalina.properties:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
I've dumped a few dozen jars in the shared/lib directory. These are found
when I start Tomcat, but the jars in a deployed WAR are not found. The
problem manifests itself as a ClassNotFoundException on on
org.hibernate.SessionFactory, which is located in the web app's WEB-INF/lib
directory, and not the shared/lib directory. As a test, I added the web
app's lib dir to the shared loader, like this:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar,${catalina.base}/webapps/WorkList/WEB-INF/lib/*.jar
That's obviously bad as an actual fix, but the app loads in that
configuration. Any ideas? What I'd like is the shared class loader as a
supplement to the webapp classloader.
At a guess, something in shared depends on hibernate. The shared loader
is visible to the web app but the web app loader is not visible to shared.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Shared jars
I explored that suggestion. The class failing to load is
org.hibernate.SessionFactory, and the class attempting to load it is
HibernateGrailsPlugin. The former class is confirmed in a jar in
WEB-INF/lib, and the latter is a .class file in WEB-INF/classes. It seems
like this should work.
The details:
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'pluginManager' defined in ServletContext resource
[/WEB-INF/applicationContext.xml]: Invocation of init method failed; nested
exception is
org.codehaus.groovy.grails.exceptions.NewInstanceCreationException: Could
not create a new instance of class [HibernateGrailsPlugin]!
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:850)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:724)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by:
org.codehaus.groovy.grails.exceptions.NewInstanceCreationException: Could
not create a new instance of class [HibernateGrailsPlugin]!
... 20 more
Caused by: java.lang.NoClassDefFoundError: org/hibernate/SessionFactory
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getDeclaredMethods(Class.java:1791)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:33)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:20)
at HibernateGrailsPlugin.init(HibernateGrailsPlugin.groovy:43)
... 20 more
Caused by: java.lang.ClassNotFoundException: org.hibernate.SessionFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at java.lang.ClassLoader.loadClass(ClassLoader.java:254)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399)
... 27 more
Tim
On Fri, Sep 11, 2009 at 4:36 AM, Mark Thomas ma...@apache.org wrote:
Tim Berglund wrote:
I'm trying to enable the shared classloader on Tomcat 6.0.20 (Java
1.6.0_15
on Mac OSX 10.6). I've put this line in conf/catalina.properties:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
I've dumped a few dozen jars in the shared/lib directory. These are found
when I start Tomcat, but the jars in a deployed WAR are not found. The
problem manifests itself as a ClassNotFoundException on on
org.hibernate.SessionFactory, which is located in the web app's
WEB-INF/lib
directory, and not the shared/lib directory. As a test, I added the web
app's lib dir to the shared loader, like this:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar,${catalina.base}/webapps/WorkList/WEB-INF/lib/*.jar
That's obviously bad as an actual fix, but the app loads in that
configuration. Any ideas? What I'd like is the shared class loader as a
supplement to the webapp classloader.
At a guess, something in shared depends on hibernate. The shared loader
is visible to the web app but the web app loader is not visible to shared.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Shared jars
From: Tim Berglund [mailto:tlbergl...@gmail.com] Subject: Re: Shared jars The class failing to load is org.hibernate.SessionFactory Any chance the above class is in more than one place in this branch of the classloader tree? An NCDFE can result from that condition as well as the class simply not being there (or accessible). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Shared jars
I'm trying to enable the shared classloader on Tomcat 6.0.20 (Java 1.6.0_15
on Mac OSX 10.6). I've put this line in conf/catalina.properties:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar
I've dumped a few dozen jars in the shared/lib directory. These are found
when I start Tomcat, but the jars in a deployed WAR are not found. The
problem manifests itself as a ClassNotFoundException on on
org.hibernate.SessionFactory, which is located in the web app's WEB-INF/lib
directory, and not the shared/lib directory. As a test, I added the web
app's lib dir to the shared loader, like this:
shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar,${catalina.base}/webapps/WorkList/WEB-INF/lib/*.jar
That's obviously bad as an actual fix, but the app loads in that
configuration. Any ideas? What I'd like is the shared class loader as a
supplement to the webapp classloader.
Many thanks for your help!
Tim Berglund
