cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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 - http://www.anyware-tech.com

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


Mime
View raw message