You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by bl...@locus.apache.org on 2000/11/29 17:55:27 UTC
cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
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.
Revision Changes Path
No revision
No revision
1.1.2.10 +5 -5 xml-cocoon/src/org/apache/cocoon/generation/Attic/PhpGenerator.java
Index: PhpGenerator.java
===================================================================
RCS file: /home/cvs/xml-cocoon/src/org/apache/cocoon/generation/Attic/PhpGenerator.java,v
retrieving revision 1.1.2.9
retrieving revision 1.1.2.10
diff -u -r1.1.2.9 -r1.1.2.10
--- PhpGenerator.java 2000/11/29 12:17:59 1.1.2.9
+++ PhpGenerator.java 2000/11/29 16:55:14 1.1.2.10
@@ -28,9 +28,9 @@
* results into SAX events.
*
* @author <a href="mailto:rubys@us.ibm.com">Sam Ruby</a>
- * @version CVS $Revision: 1.1.2.9 $ $Date: 2000/11/29 12:17:59 $
+ * @version CVS $Revision: 1.1.2.10 $ $Date: 2000/11/29 16:55:14 $
*/
-public class PhpGenerator extends ServletGenerator, Poolable {
+public class PhpGenerator extends ServletGenerator implements Poolable {
/**
* Stub implementation of Servlet Config
@@ -83,7 +83,7 @@
}
/******************************************************************/
- /* runnable interface */
+ /* runnable interface */
/******************************************************************/
public void run() {
@@ -116,7 +116,7 @@
try {
// construct both ends of the pipe
PipedInputStream input = new PipedInputStream();
-
+
// start PHP producing results into the pipe
PhpServlet php = new PhpServlet();
php.init(new config(context));
@@ -141,5 +141,5 @@
} catch (Exception e) {
throw new IOException(e.toString());
}
- }
+ }
}
No revision
No revision
1.1.4.32 +23 -3 xml-cocoon/src/org/apache/cocoon/servlet/Attic/CocoonServlet.java
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
--- CocoonServlet.java 2000/11/17 20:28:34 1.1.4.31
+++ CocoonServlet.java 2000/11/29 16:55:19 1.1.4.32
@@ -17,6 +17,8 @@
import java.net.MalformedURLException;
import java.net.URL;
+import java.util.StringTokenizer;
+
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
@@ -52,7 +54,7 @@
* (Apache Software Foundation, Exoffice Technologies)
* @author <a href="mailto:stefano@apache.org">Stefano Mazzocchi</a>
* @author <a href="mailto:nicolaken@supereva.it">Nicola Ken Barozzi</a> Aisa
- * @version CVS $Revision: 1.1.4.31 $ $Date: 2000/11/17 20:28:34 $
+ * @version CVS $Revision: 1.1.4.32 $ $Date: 2000/11/29 16:55:19 $
*/
public class CocoonServlet extends HttpServlet {
@@ -82,7 +84,7 @@
try {
String path = "file://" +
- this.context.getRealPath("/") +
+ this.context.getRealPath("/") +
"/WEB-INF/logs/cocoon.log";
log = LogKit.createLogger("cocoon", path, "DEBUG");
} catch (Exception e) {
@@ -116,6 +118,24 @@
this.workDir = ((File) this.context.getAttribute("javax.servlet.context.tempdir")).toString();
+ String forceLoading = conf.getInitParameter("force-load");
+ if (forceLoading != null) {
+ StringTokenizer fqcnTokenizer = new StringTokenizer(forceLoading, ",", false);
+
+ while (fqcnTokenizer.hasMoreTokens()) {
+ String fqcn = fqcnTokenizer.nextToken();
+
+ try {
+ Class.forName(fqcn);
+ } catch (Exception e) {
+ log.error("Could not force-load class: " + fqcn, e);
+ this.context.log("Could not force-load class: " + fqcn, e);
+ throw new ServletException("Could not force-load the required class: " +
+ fqcn + "\n" + e.getMessage(), e);
+ }
+ }
+ }
+
String configFileName = conf.getInitParameter("configurations");
if (configFileName == null) {
throw new ServletException("Servlet initialization argument 'configurations' not specified");
@@ -125,7 +145,7 @@
}
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);
No revision
No revision
1.1.2.5 +0 -1 xml-cocoon/xdocs/Attic/book.xml
Index: book.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/Attic/book.xml,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- book.xml 2000/11/24 21:33:38 1.1.2.4
+++ book.xml 2000/11/29 16:55:21 1.1.2.5
@@ -7,7 +7,6 @@
<page id="install" label="Install" source="installing.xml"/>
<separator/>
<page id="overview" label="Overview" source="overview.xml"/>
- <page id="landscape" label="Landscapes" source="emotional-landscapes.xml"/>
<page id="httprequest" label="HttpRequest" source="httprequest.xml"/>
<page id="avalon" label="Avalon" source="avalon.xml"/>
<page id="extending" label="Extending" source="extending.xml"/>
1.1.2.2 +1 -1 xml-cocoon/xdocs/Attic/changes.xml
Index: changes.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/Attic/changes.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- changes.xml 2000/11/20 11:56:05 1.1.2.1
+++ changes.xml 2000/11/29 16:55:22 1.1.2.2
@@ -4,7 +4,7 @@
<!--
History of Cocoon changes
- $Id: changes.xml,v 1.1.2.1 2000/11/20 11:56:05 dims Exp $
+ $Id: changes.xml,v 1.1.2.2 2000/11/29 16:55:22 bloritsch Exp $
-->
<changes title="History of Changes">
@@ -20,7 +20,7 @@
<person name="Ricardo Rocha" email="ricardo@apache.org" id="RR"/>
</devs>
- <release version="2.0a3" date="November 20 2000">
+ <release version="2.0a3" date="November 29 2000">
<action dev="DB" type="add">
added esql logicsheet to c2
</action>
1.1.2.2 +0 -0 xml-cocoon/xdocs/Attic/todo.xml
Index: todo.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/Attic/todo.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- todo.xml 2000/11/20 11:56:08 1.1.2.1
+++ todo.xml 2000/11/29 16:55:23 1.1.2.2
@@ -4,7 +4,7 @@
<!--
History of Cocoon changes
- $Id: todo.xml,v 1.1.2.1 2000/11/20 11:56:08 dims Exp $
+ $Id: todo.xml,v 1.1.2.2 2000/11/29 16:55:23 bloritsch Exp $
-->
Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Giacomo Pati <gi...@apache.org>.
bloritsch@locus.apache.org wrote:
<snip/>
> +
> + try {
> + Class.forName(fqcn);
> + } catch (Exception e) {
> + log.error("Could not force-load class: " + fqcn, e);
Berin, could you use the methods of the ClassUtil class to load the
classes. I remember Stefano saying we should have all class loading in
one place (IIRC it has to do with classloader issues which can arise
otherwise)
<snip/>
> <page id="overview" label="Overview" source="overview.xml"/>
> - <page id="landscape" label="Landscapes" source="emotional-landscapes.xml"/>
> <page id="httprequest" label="HttpRequest" source="httprequest.xml"/>
Do you had any reasons to remove Stefanos "Emotional Landscapes"
document?
Giacomo
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.
[MiniVote] Re: cvs commit: xml-cocoon/xdocs book.xml changes.xml todo.xml
Posted by Paul Russell <pa...@luminas.co.uk>.
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.