cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Langham" <mlang...@sundn.de>
Subject AW: [MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Date Thu, 07 Dec 2000 12:25:37 GMT
>>
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                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.


Mime
View raw message