cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject RE: Problems with C2 and Tomcat 3.3
Date Mon, 29 Oct 2001 08:00:33 GMT
Hi,

as this patch is required for Cocoon to work with T3.3
(and maybe other servlet engines), I also added it
to the 20 branch.

Thanks Ovidiu for the patch,

Carsten

> -----Original Message-----
> From: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> Sent: Monday, October 29, 2001 4:45 AM
> To: costinm@covalent.net; Carsten Ziegeler; Berin Loritsch
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: Problems with C2 and Tomcat 3.3
>
>
> Thanks Costin for the analysis.
>
> Carsten, Berin, based on Costin's remarks, the following patch
> included in CVS, fixes the problem on Tomcat 3.3.
>
> It creates the temporary files in a subdirectory inside the work
> directory, instead of having them directly there. This hides the
> temporary files from Tomcat, thus eliminating the reloading of the
> whole Cocoon application when a temp file (like the sitemap or an XSP)
> is recompiled.
>
> Index: CocoonServlet.java
> ===================================================================
> RCS file:
> /home/cvs/xml-cocoon2/src/org/apache/cocoon/servlet/CocoonServlet.java,v
> retrieving revision 1.46
> diff -u -c -r1.46 CocoonServlet.java
> *** CocoonServlet.java	2001/10/23 11:44:14	1.46
> --- CocoonServlet.java	2001/10/29 03:26:44
> ***************
> *** 145,150 ****
> --- 145,151 ----
>               workDir.mkdirs();
>           } else {
>               workDir = (File)
> this.servletContext.getAttribute("javax.servlet.context.tempdir");
> +             workDir = new File(workDir, "cocoon2-files");
>           }
>
>           this.appContext.put(Constants.CONTEXT_WORK_DIR, workDir);
>
> Regards,
> Ovidiu
>
> On Fri, 26 Oct 2001 14:18:52 -0700 (PDT), <costinm@covalent.net> wrote:
>
> > 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


Mime
View raw message