cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: classDirURL = jndi protocol?!
Date Wed, 31 Oct 2001 15:43:07 GMT

Carsten Ziegeler a écrit :
> Hi John,
> first, you are not using the cocoon_20_branch. I changed only
> the HEAD of the cvs.
> Now, the changes are required to get rid of the getRealPath() calls
> which will not work if you are using a war Cocoon as a war file and
> the servlet engine does not unpack it.
> As we can't use getRealPath(), we have problems with building the
> classpath anyway, as we can't scan the WEB-INF directory anymore.
> I currently see only two choices:
> 1) use getRealPath() and we won't run as a war file.
> 2) don't use getRealPath() and we can't use our own classloader.
>    And so Cocoon does not run in many servlet engines due to
>    class conflicts.
> I hope there is a third solution. We could of course do a combination:
> a) Test if getRealPath() can be used and then create our own classloader
> b) if getRealPath() is not working we hope that the servlet engine
>    does not cause any class conflicts.
> So any suggestions are welcome.
> Carsten

This is a complex problem, and I'm afraid there's no universal solution

We cannot assume getResource() returns a "file:" URL, even if the
resource is actually one. With a directory context in Tomcat 4 (not a
war file), getResource("/WEB-INF/classes") returns
"jndi:/localhost/cocoon/WEB-INF/classes" which obviously isn't a "file:"
URL, while getRealPath("/WEB-INF/classes") returns
"/path-to-webapps/cocoon/WEB-INF/classes", which is what we want.

So, we should use getRealPath() where a filename is needed (i.e. a name
in the file system), and getResource() everywhere else.

The main (only ?) place where filenames are required is for building the
classpath used by javac for sitemap/xsp compilation, since javac doesn't
use the current classloader, but the classpath given on the command
line. So this area *must* use getRealPath().

If getRealPath() returns null because of a non-expanded war file, I'm
afraid there is no way to build a valid classpath. IIRC, there used to
be in the past some additional tests in CocoonServlet for
container-specific attributes in the ServletContext giving the classpath
used for JSP compilation. This is the only fallback whe have to get the
classpath in that case.

My .02 euro.
Sylvain Wallez
Anyware Technologies -

To unsubscribe, e-mail:
For additional commands, email:

View raw message