cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <>
Subject Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Date Thu, 07 Dec 2000 14:36:06 GMT
On Thu, Dec 07, 2000 at 09:05:31AM -0500, Berin Loritsch wrote:
> ----- Original Message ----- 
> From: "Paul Russell" <>
> To: <>
> Sent: Thursday, December 07, 2000 4:40 AM
> Subject: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
> > The above change breaks Cocoon2 in JRun3.0, because JRun handles
> > resources using a custom URL scheme (entirely valid behaviour).
> > Is there a reason why WebSphere needs to use the above, uh,
> > workaround? The file portion of a URL is *not* the same as a
> > filename on disk.
> I appologize for this.  What you see now is what was in Cocoon
> before I changed it to getRealPath to make things work in
> WebSphere.  When I got a fix (the force-load parameter) for
> making the old way work again, I reimplemented the old way.

Ahh right. I wasn't sure whether the reversion was part of the
fix, or whether it was just a slipup. My problem is that the
current implementation makes some very large (and inaccurate
in JRun) assumptions about the URL.
> > If websphere doesn't like 'getRealPath', then we probably need
> > to refactor, and to use
> > URLs to represent the location of the configuration file -- that
> > way we move over to something which should work across *all*
> > servlet containers (although getRealPath should work in 90% of
> > them, too).
> I think that ultimately this is the way to go.  The question is
> whether context.getResource() will work with files stored in the
> jar file (i.e. the sitmap.xsl, xsp.xsl, etc.) as well.  The Cocoon
> object should change the arguments from "String pathToResource"
> to "URL forResource" signatures.  For Example:
> ...
> public Cocoon(File configFile, String classpath, String workDir) {}
> ...
> should be changed to:
> ...
> public Cocoon(URL configFile, String classpath, File workDir) {}
> ...

Yep, indeed.

> The servlet engine returns a File object for the Work Directory.
> This is important because the default URL handler for the "file"
> protocol does not let you write effectively (sometimes it does,
> but if anything in the URL points to something that doesn't exist,
> then it doesn't).  Unless we want to reimplement the URL handlers
> I suggest keeping that a File object.

That's fine - as long as it fits the servlet API and works, I'm happy.

> The resources are always URLs, and it is better to let the Servlet
> Engine figure out what kind of protocol they want to give it to you
> as than to change it.  It is easier to convert from a File object
> to a URL than the other way around.


> > Can I have a quick show of integers (i.e. a vote) on changing
> >, and to using URLs to
> > manage and load the cocoon configurations.
> +1 for the URL approach.


> How about the Context approach?  e.g.
> ...
> public Cocoon(CocoonContext context) {}
> ...
> The Main and CocoonServlet objects would populate the proxy object,
> so that anything that as the number of arguments grow or shrink,
> we don't have to change the signature.

I'm not sure about this - it could be overkill, but I do see
your thinking.


Paul Russell                               <>
Technical Director,         
Luminas Ltd.

View raw message