Problems with C2 and Tomcat 3.3

[Carsten Ziegeler <cz...@sundn.de>]

Hi,

does anyone have problems with the latest Tomcat 3.3, too?

Everything is working fine, until you change the sitemap.
The sitemap is correctly regenerated, but the loading of
the compiled class seems not to work.
No exception or warning occurs, but after
the regeneration the old class is still used.

Any hints?

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Problems with C2 and Tomcat 3.3

[co...@covalent.net]

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 )

Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Problems with C2 and Tomcat 3.3

[Berin Loritsch <bl...@apache.org>]

Carsten Ziegeler wrote:
> 
> Berin Loritsch wrote:
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi,
> > >
> > > does anyone have problems with the latest Tomcat 3.3, too?
> > >
> > > Everything is working fine, until you change the sitemap.
> > > The sitemap is correctly regenerated, but the loading of
> > > the compiled class seems not to work.
> > > No exception or warning occurs, but after
> > > the regeneration the old class is still used.
> > >
> > > Any hints?
> >
> > I experience this as well.  It might be related to container
> > classloader issues.  I.e. does Tomcat 3.3 use the work directory
> > for JSP pages?  If so, than it is reasonable to assume that
> > Tomcat 3.3 is the culprit with a defective classloader.
> >
> 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.

If that doesn't work, we are at Tomcat's mercy.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: Problems with C2 and Tomcat 3.3

[Carsten Ziegeler <cz...@sundn.de>]

Berin Loritsch wrote:
> 
> Carsten Ziegeler wrote:
> > 
> > Hi,
> > 
> > does anyone have problems with the latest Tomcat 3.3, too?
> > 
> > Everything is working fine, until you change the sitemap.
> > The sitemap is correctly regenerated, but the loading of
> > the compiled class seems not to work.
> > No exception or warning occurs, but after
> > the regeneration the old class is still used.
> > 
> > Any hints?
> 
> I experience this as well.  It might be related to container
> classloader issues.  I.e. does Tomcat 3.3 use the work directory
> for JSP pages?  If so, than it is reasonable to assume that
> Tomcat 3.3 is the culprit with a defective classloader.
> 
Can we do anything to make it work? Or do we need to pass this
on to the Tomcat developers?

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Problems with C2 and Tomcat 3.3

[Berin Loritsch <bl...@apache.org>]

Carsten Ziegeler wrote:
> 
> Hi,
> 
> does anyone have problems with the latest Tomcat 3.3, too?
> 
> Everything is working fine, until you change the sitemap.
> The sitemap is correctly regenerated, but the loading of
> the compiled class seems not to work.
> No exception or warning occurs, but after
> the regeneration the old class is still used.
> 
> Any hints?

I experience this as well.  It might be related to container
classloader issues.  I.e. does Tomcat 3.3 use the work directory
for JSP pages?  If so, than it is reasonable to assume that
Tomcat 3.3 is the culprit with a defective classloader.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org