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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 29, 2001 4:45 AM > To: [EMAIL PROTECTED]; Carsten Ziegeler; Berin Loritsch > Cc: [EMAIL PROTECTED] > 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), <[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]
