> -----Original Message-----
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 31 October 2001 3:43 pm
> To: [EMAIL PROTECTED]
> Subject: Re: classDirURL = jndi protocol?!
>
>
>
>
> 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.
So; should I put the code back to how it was prior to the getRealPath ->
getResource conversion or add tests for "if(servletContextPath != null)" and
make the decision based on that?
Can't we use the jndi protocol to get at the jar files?
> My .02 euro.
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
