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 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 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. >> >> 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
