cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: Class loading and simplifying Cocoon installation
Date Wed, 07 Feb 2001 20:57:24 GMT
Simon Waddington wrote:
> Maybe this feature is in C2 (I confess I haven't been following it too
> closely) but wouldn't it simplify Cocoon installation and usage greatly if
> it could be distributed as a simple web app archive.  Almost all servlet
> engines (JServ seems to be the only pre-servlet 2.2 engine in common usage)
> these days support a .war file directly, or if not, will support an unpacked
> .war file.

As much as is possible, in Cocoon 2 this is already done.

> I've found so far that the only issues with Cocoon that hampers this are
> that:
> a) some servers include incompatible XML parser classes in the system path

In a servlet 2.3 compliant engine this can be fixed.  In a servlet 2.2 compliant
engine, you have some creative classpath work to do.

> b) that the XSP engine does not find the Cocoon and other required classes
> at compile time

This is a result of the necessity of reading a servlet engine specific
property--that is not guaranteed to be there for all servlet engines.  Basically
you need to read a property that gives you the runtime servlet ClassPath that
is being used.  Another way around this is to build it dynamically using
File paths.  Note: this will break Servlet 2.0 compatibility....

> c) repositories and other files should really be contained within the
> WEB-INF dir (but don't actually need to be, its just a cleaner and more
> portable install).

No.  According to Servlet 2.2 and greater specs, you can ask the Servlet
engine for the Repository directory (work directory).  It will give it
to you.  Again, this will break Servlet 2.0 compatibility....

> I don't think there is a way around a) except to modify the system path for
> the server.  Shame.  So far I've only found that Tomcat 3.x is suffering
> this problem, but there are probably other servers that have it.
> But b) looks emminently fixable - either by modifying the XSPClassloader (is
> this actually used during compilation - I haven't figured that one out, if
> not it seems to me it could be), or by wailing on the -classpath or -extdirs
> option of Javac and hopefully Jikes (I haven't checked to see if Jikes
> supports -extdirs).

The -classpath option is used on both compilers already.  Cocoon gets the
classpath from the System, which is why it needs to be there.  As I meantioned
earlier, Cocoon 2 solves the issue with a Servlet Engine specific attribute.
As long as the Servlet Engine has that attribute, it can use it and be
completely contained.

> c) is easily fixable too.
> Does anyone else think the benefits would be worth making the moving towards
> better servlet 2.2+ and app server compatibility?

As far as I know, there are *alot* of people who need Cocoon 1 to remain
Java 1.1 and Servlet 2.0 compatible--because they are using FreeBSD which
doesn't have a native Java 1.2 or greater JDK yet.

Cocoon 2 addresses the need for moving to more recent specs, so more
effort has gone into making it work there.

View raw message