cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignacio J. Ortega" <na...@siapi.es>
Subject RE: Problems with C2 and Tomcat 3.3
Date Fri, 26 Oct 2001 22:17:11 GMT
What i dont understand now.., is how this had worked before with 3.3 :),
as i see it never was working, and my colleagues that use C2 simply dont
complained about that.., they restarted tc every time sitemap was
modified, and continued the work.. :(..,

But from my understanding of how this works on tc3.3, work dir is added
to the webapp classloader sooooo, there was no posibility to c2 had this
working at anytime before :) , or at least in the last 10 months.., i
know what i say.. i added work dir to the CL in first place :).. I
recall we need it to load jsps when using JspInterceptor in nonservlet
mode...

A easy workaround is to add useJspServlet="true" in the JspInterceptor
line..

To see it add debug="10" to the LoaderInterceptor11 line in server.xml,
you should see the classpath of every context logged..

And yes the solution is to add a directory in workdir and use it for
cocoon's own compiled classes.., so sitemap class is not found by the
webapp CL, that adds work dir to his list of repositoires..

And in addition i think we could do the same in tc3.3, use a directory
inside workdir for compiled jsps, i think this fix should go in 3.3.1 as
it's so easy to do..

Saludos ,
Ignacio J. Ortega


> -----Mensaje original-----
> De: Berin Loritsch [mailto:bloritsch@apache.org]
> Enviado el: viernes 26 de octubre de 2001 17:11
> Para: Carsten Ziegeler
> Cc: Ignacio J. Ortega
> Asunto: Re: Problems with C2 and Tomcat 3.3
> 
> 
> Carsten Ziegeler wrote:
> > 
> > Hi Ignacio, hi Berin,
> > 
> > just a little update:
> > 
> > If the compiled class is not directly written to the work directory
> > for the cocoon webapp, but to a subdirectory (as Berin suggested),
> > everything is working fine.
> 
> How quickly can it be incorporated into a release?
> Realistically though, if one Servlet Container does it, there might
> be others.  I think it would be the safest route in the long term.
> 
> > Ignacio, is this the solution we have to choose or can anything
> > be done about that in Tomcat?
> > 
> > Regards,
> > 
> > Carsten
> > 
> > >
> > > Hola Carsten, Berin:
> > >
> > > ( Sorry to contact you directly but lists are slow this days )
> > >
> > > Normally i use a cocoon_20_branch Coocon2, doing 
> extensive edits on
> > > master sitemap and everything is working nice here with 3.3, i'm
> > > committer to TC3.3.., so dont hesitate to contact me if you need
> > > something to isolate the problem.. i've normally lurk on 
> Cocoon-dev..so
> > > i've stay informed..
> > >
> > >
> > > Saludos ,
> > > Ignacio J. Ortega
> > >
> > >
> > > > -----Mensaje original-----
> > > > De: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > > > Enviado el: jueves 25 de octubre de 2001 8:53
> > > > Para: cocoon-dev@xml.apache.org
> > > > Asunto: RE: Problems with C2 and Tomcat 3.3
> > > >
> > > >
> > > >
> > > > 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
> > > >
> > > >
> 

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


Mime
View raw message