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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
