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), <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
