cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Date Thu, 07 Dec 2000 14:05:31 GMT
----- 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

> >   Index:
> >   ===================================================================
> >   RCS file: /home/cvs/xml-cocoon/src/org/apache/cocoon/servlet/Attic/,v
> >   retrieving revision
> >   retrieving revision
> >   diff -u -r1.1.4.31 -r1.1.4.32
> [...]
> >            try {
> >   -            this.configFile = new File(this.context.getRealPath(configFileName));
> >   +            this.configFile = new File(this.context.getResource(configFileName).getFile());
> >            } catch (Exception mue) {
> >                this.context.log("Servlet initialization argument 'configurations'
not found at " + configFileName, mue);
> >                log.error("Servlet initialization argument 'configurations' not found
at " + configFileName, mue);
> 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.

> 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) {}

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.

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.

View raw message