cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Problems with C2 and Tomcat 3.3
Date Fri, 26 Oct 2001 21:18:52 GMT
On Thu, 25 Oct 2001, Berin Loritsch wrote:

> > Can we do anything to make it work? Or do we need to pass this
> > on to the Tomcat developers?
> The only thing we personally could do is break the Servlet spec,
> and assign our own work directory.  I am -1 on that.  By all means,
> let's assign this to Tomcat developers.
> There is a possibility that it might start working again if we had the
> compiled classes in a subdirectory like ${work}/cocoon-classes.
> This means the packages do not apply to the root of the work directory,
> and *hopefully* Tomcat's classloader won't find them.

That's true - if you do your own dependency-checking and reloading it's
much better to use a subdir of work, and keep your classes there.

Tomcat ( the servlet container side ) checks all classes that are loaded
by its classloader - or it should. If it detects a change it will
reload the context ( i.e. _all_ servlets will be destroyed and reloaded ).
I'm not sure you want this.

Jasper uses it's own scheme to avoid full-reloads. In 3.3 it uses
a mangling scheme ( since the name of the class is not specified ),
in 4.0 it uses a separate class loader for each jsp.

In any case, the work directory is not specified in any way -
and you shouldn't rely on it beeing in the webapp loader ( or not ). For
3.x ( and I think 4.x ) it is included in the loader, and I suspect
other containers do this as well.

But there is no guarantee classes from work will be reloaded ( or
loaded ! ).

However if you create a sub-dir of work and use your class loader
you can do what you want. BTW, DependClassLoader and o.a.t.u.depend
provide a pretty efficient reloader ( it's independent of tomcat ).

BTW, full reloading is required for the 'default' reloader, since
servlets could get in an unstable state ( with objects from different
classloaders ). Shuting down the context and starting again is the
only way to do that ( AFAIK ). For JSPs and scripting systems that
use class generations you can do 'local' reloading, but if you
change any libs or objects that are not local to a page you should
do a full app reload. ( the easiest way to force one in 3.3 is
to touch web.xml )


To unsubscribe, e-mail:
For additional commands, email:

View raw message