You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/02/20 12:15:46 UTC
[c2] works!
Ok, it works.
I discovered the problem: this version of Catalina, makes a local copy
all the libs found in /WEB-INF/lib to the /work directory. So, I was
upgrading cocoon.jar in the /WEB-INF/lib but catalina was not comparing
the libraries versions and upgrading them.
Craig, two questions:
1) why is this done? is this really necessary? Cocoon holds almost 7Mb
of libraries, catalina wasn't targetted for embedded systems as well? so
why this duplication?
In case this is absolutely necessary:
2) could you please make Catalina check at runtime the difference
between /WEB-INF/lib and /work/[webapp]/WEB-INF/lib and synch them? I'm
pretty sure this will cause *lots* of confusion in the future for users
since if you upgrade the webapp but don't remove the work directory by
hand, the webapp is very likely not to change behavior and this normally
results in thinking that is your webapp's fault, not the container's.
[like it happened to me in this case when I upgraded cocoon.jar without
removing the work directory]
TIA
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: [c2] works!
Posted by Stefano Mazzocchi <st...@apache.org>.
"Craig R. McClanahan" wrote:
>
> Stefano Mazzocchi wrote:
>
> > Ok, it works.
> >
>
> Awesome!
Hold it, I haven't tried your classpath trick yet, so I'm saying that
Cocoon2 is back functional after Berin's changes, for now I still have
to add 'servlet.jar' in the system classpath.
> >
> > I discovered the problem: this version of Catalina, makes a local copy
> > all the libs found in /WEB-INF/lib to the /work directory. So, I was
> > upgrading cocoon.jar in the /WEB-INF/lib but catalina was not comparing
> > the libraries versions and upgrading them.
> >
> > Craig, two questions:
> >
> > 1) why is this done? is this really necessary? Cocoon holds almost 7Mb
> > of libraries, catalina wasn't targetted for embedded systems as well? so
> > why this duplication?
> >
>
> This version of Tomcat 4.0 lets you run a web application directly out of a
> WAR file if you want to. That works great for everything except compiling
> -- where's the standard compiler API when we need it?
no shit :)
> -- so we duplicate the
> classes and libraries out of the WAR so that you can pass them to the
> compiler on a classpath.
Makes perfect sense.
> I wasn't aware we were doing this even if the webapp was in an unpacked
> directory. That seems like overkill.
Yeah, exactly.
> Remy, can you look at this please?
Thanks.
> >
> > In case this is absolutely necessary:
> >
> > 2) could you please make Catalina check at runtime the difference
> > between /WEB-INF/lib and /work/[webapp]/WEB-INF/lib and synch them? I'm
> > pretty sure this will cause *lots* of confusion in the future for users
> > since if you upgrade the webapp but don't remove the work directory by
> > hand, the webapp is very likely not to change behavior and this normally
> > results in thinking that is your webapp's fault, not the container's.
> > [like it happened to me in this case when I upgraded cocoon.jar without
> > removing the work directory]
> >
>
> Yah, this is just as bad as the old Tomcat 3.1 habit of not re-expanding a
> WAR file at all, even if it is newer.
yep... on this tune: is there a way to specify that catalina should
*NOT* remove the expanded webapp when it shuts down? In the future,
Cocoon2 will probably have the ability to "precompile" everything (both
XSP and XML files) into a war file so this requirement goes away, but in
many cases, you modify the webapp *after* you deploy it... and then if
you shutdown catalina, boom, everything is gone again.
I know this is a bad practice (I totally agree) but such behavior should
be at least configurable at a webapp granularity.
> If we are going to expand (from a WAR), we should probably replace any
> previously expanded contents unconditionally -- otherwise, clock skew
> problems could still bite us, especially on networked file systems.
Good point.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: [c2] works!
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Stefano Mazzocchi wrote:
> Ok, it works.
>
Awesome!
>
> I discovered the problem: this version of Catalina, makes a local copy
> all the libs found in /WEB-INF/lib to the /work directory. So, I was
> upgrading cocoon.jar in the /WEB-INF/lib but catalina was not comparing
> the libraries versions and upgrading them.
>
> Craig, two questions:
>
> 1) why is this done? is this really necessary? Cocoon holds almost 7Mb
> of libraries, catalina wasn't targetted for embedded systems as well? so
> why this duplication?
>
This version of Tomcat 4.0 lets you run a web application directly out of a
WAR file if you want to. That works great for everything except compiling
-- where's the standard compiler API when we need it? -- so we duplicate the
classes and libraries out of the WAR so that you can pass them to the
compiler on a classpath.
I wasn't aware we were doing this even if the webapp was in an unpacked
directory. That seems like overkill. Remy, can you look at this please?
>
> In case this is absolutely necessary:
>
> 2) could you please make Catalina check at runtime the difference
> between /WEB-INF/lib and /work/[webapp]/WEB-INF/lib and synch them? I'm
> pretty sure this will cause *lots* of confusion in the future for users
> since if you upgrade the webapp but don't remove the work directory by
> hand, the webapp is very likely not to change behavior and this normally
> results in thinking that is your webapp's fault, not the container's.
> [like it happened to me in this case when I upgraded cocoon.jar without
> removing the work directory]
>
Yah, this is just as bad as the old Tomcat 3.1 habit of not re-expanding a
WAR file at all, even if it is newer.
If we are going to expand (from a WAR), we should probably replace any
previously expanded contents unconditionally -- otherwise, clock skew
problems could still bite us, especially on networked file systems.
>
> TIA
>
Craig
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------