"Morrison, John" a écrit :
>
> > -----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?
>
No, because we want to be able to list the contents of a directory. We
should switch back to getRealPath() all classpath stuff in
CocoonServlet.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
