cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: Problems with C2 and Tomcat 3.3
Date Mon, 29 Oct 2001 03:45:06 GMT
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