You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Paul Russell <pa...@luminas.co.uk> on 2000/12/07 10:40:54 UTC
[MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
On Wed, Nov 29, 2000 at 04:55:27PM -0000, bloritsch@locus.apache.org wrote:
> bloritsch 00/11/29 08:55:25
>
> Modified: src/org/apache/cocoon/generation Tag: xml-cocoon2
> PhpGenerator.java
> src/org/apache/cocoon/servlet Tag: xml-cocoon2
> CocoonServlet.java
> xdocs Tag: xml-cocoon2 book.xml changes.xml todo.xml
> Log:
> Changed back to getResource(), implemented "force-load" init
> parameter--still works with WebSphere.
[...]
> Index: CocoonServlet.java
> ===================================================================
> RCS file: /home/cvs/xml-cocoon/src/org/apache/cocoon/servlet/Attic/CocoonServlet.java,v
> retrieving revision 1.1.4.31
> retrieving revision 1.1.4.32
> 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.
If websphere doesn't like 'getRealPath', then we probably need
to refactor Cocoon.java, CocoonServlet.java and Main.java 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).
Can I have a quick show of integers (i.e. a vote) on changing
Cocoon.java, CocoonServlet.java and Main.java to using URLs to
manage and load the cocoon configurations.
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Paul Russell <pa...@luminas.co.uk>.
On Thu, Dec 07, 2000 at 09:52:34AM -0500, Berin Loritsch wrote:
> > I'm not sure about this - it could be overkill, but I do see
> > your thinking.
> Well, I am thinking about how to get the ServletContext object to
> Cocoon, and see if I can do the getResource() for things inside
> jars. Basically, I want to be able to embed all the jars inside
> the Webapp classpath, and have it work with all servlet engines.
> It's easier said than done, though.
Tell me about it. If you want to give it a whirl, that's fine
by me. Let me know if you want any help from me (sorting out
the URL problems first or whatever?)
Paul.
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Berin Loritsch <bl...@infoplanning.com>.
> > 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.
Well, I am thinking about how to get the ServletContext object to
Cocoon, and see if I can do the getResource() for things inside
jars. Basically, I want to be able to embed all the jars inside
the Webapp classpath, and have it work with all servlet engines.
It's easier said than done, though.
Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Paul Russell <pa...@luminas.co.uk>.
On Thu, Dec 07, 2000 at 09:05:31AM -0500, Berin Loritsch wrote:
> ----- Original Message -----
> From: "Paul Russell" <pa...@luminas.co.uk>
> To: <co...@xml.apache.org>
> 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 Cocoon.java, CocoonServlet.java and Main.java 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.
Indeed.
> > Can I have a quick show of integers (i.e. a vote) on changing
> > Cocoon.java, CocoonServlet.java and Main.java to using URLs to
> > manage and load the cocoon configurations.
> +1 for the URL approach.
K.
> 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.
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Berin Loritsch <bl...@infoplanning.com>.
----- Original Message -----
From: "Paul Russell" <pa...@luminas.co.uk>
To: <co...@xml.apache.org>
Sent: Thursday, December 07, 2000 4:40 AM
Subject: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
> > Index: CocoonServlet.java
> > ===================================================================
> > RCS file: /home/cvs/xml-cocoon/src/org/apache/cocoon/servlet/Attic/CocoonServlet.java,v
> > retrieving revision 1.1.4.31
> > retrieving revision 1.1.4.32
> > 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 Cocoon.java, CocoonServlet.java and Main.java 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
> Cocoon.java, CocoonServlet.java and Main.java 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.
AW: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Matthew Langham <ml...@sundn.de>.
>>
Can I have a quick show of integers (i.e. a vote) on changing
Cocoon.java, CocoonServlet.java and Main.java to using URLs to
manage and load the cocoon configurations.
<<
+1
..on anything that will allow Cocoon to run on more platforms.
Matthew Langham
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprungliche Nachricht-----
Von: Paul Russell [mailto:paulr@luminas.co.uk]Im Auftrag von Paul
Russell
Gesendet: Donnerstag, 7. Dezember 2000 10:41
An: cocoon-dev@xml.apache.org
Betreff: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml
changes.xml todo.xml
On Wed, Nov 29, 2000 at 04:55:27PM -0000, bloritsch@locus.apache.org wrote:
> bloritsch 00/11/29 08:55:25
>
> Modified: src/org/apache/cocoon/generation Tag: xml-cocoon2
> PhpGenerator.java
> src/org/apache/cocoon/servlet Tag: xml-cocoon2
> CocoonServlet.java
> xdocs Tag: xml-cocoon2 book.xml changes.xml todo.xml
> Log:
> Changed back to getResource(), implemented "force-load" init
> parameter--still works with WebSphere.
[...]
> Index: CocoonServlet.java
> ===================================================================
> RCS file:
/home/cvs/xml-cocoon/src/org/apache/cocoon/servlet/Attic/CocoonServlet.java,
v
> retrieving revision 1.1.4.31
> retrieving revision 1.1.4.32
> 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.
If websphere doesn't like 'getRealPath', then we probably need
to refactor Cocoon.java, CocoonServlet.java and Main.java 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).
Can I have a quick show of integers (i.e. a vote) on changing
Cocoon.java, CocoonServlet.java and Main.java to using URLs to
manage and load the cocoon configurations.
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.