Hi Konstantin, On Mon, 2010-01-11 at 05:19 +0300, Konstantin Kolinko wrote: > 2010/1/11 Martin Grotzke <martin.grot...@javakaffee.de>: > > On Mon, 2010-01-11 at 02:54 +0300, Konstantin Kolinko wrote: > >> 2010/1/10 Martin Grotzke <martin.grot...@javakaffee.de>: > >> > Hi, > >> > > >> > Jan 10, 2010 2:57:51 PM org.apache.catalina.connector.CoyoteAdapter > >> > service > >> > SEVERE: An exception or error occurred in the container during the > >> > request processing > >> > java.lang.NoClassDefFoundError: org/joda/time/format/ISODateTimeFormat > >> > at > >> > de.javakaffee.web.msm.serializer.javolution.JodaDateTimeFormat.<clinit>(JodaDateTimeFormat.java:35) > >> > at java.lang.Class.forName0(Native Method) > >> > at java.lang.Class.forName(Class.java:247) > >> > >> So, JodaDateTimeFormat was found and its <clinit> was called, > >> but ISODateTimeFormat was not. > > JodaDateTimeFormat is the joda DateTime serializer shipped with the > > memcached-session-manager (msm), which should be used/activated if joda > > is available in the webapp classpath. > > > > ISODateTimeFormat is a class provided by joda. > > > >> > >> Where have you placed your joda jar? > > The joda jar is placed in WEB-INF/lib of the application. I don't want > > to have this in $CATALINA_HOME/lib as joda serialization shall only be > > supported if it's required by the webapp. > > The JodaDateTimeFormat comes with the msm jar located in tomcat's lib. > > > > That won't work. > > A class loaded from Common classloader cannot depend on classes that > are in the Webapp classloader. > > Place them in the same place: > either both in WEB-INF/lib, or both in $CATALINA_HOME/lib
Thanx for this simple description, now I got it. A very simple test with my JodaDateTimeFormat placed in WEB-INF/lib is working - looks good! > > You may learn how java.lang.Class.forName() is called by the VM to > load dependent classes, but there is a simple concern, that should be > understandable: > > - when a web application is stopped (undeployed), all its assets have > to be removed from memory. > - webapp classloader belongs to the application, and takes some steps > to destroy itself, when the application is stopped > - classloader knows, what classes it has already loaded Simple, makes sense. > > When JodaDateTimeFormat class belongs to the Common classloader, it > will be loaded in memory as long as Tomcat is running, and thus cannot > depend on classes in the Webapp which are relatively short-lived. > > Implementation-wise that is class loader delegation model. The Webapp > classloader is not a parent of the Common one. Reading docs again now with your explanation and the delegation model in mind I'd say that it's already in the docs :) Thanx for your help, cheers, Martin > > >> > >> Also please read > >> http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html > > I've already done that, but I didn't find the information to solve this > > issue. Also reading again didn't help ;-) > > > > Thanx && cheers, > > Martin > > > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: This is a digitally signed message part
