You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Sergei S. Ivanov" <se...@mail.ru> on 2000/11/04 19:12:23 UTC

Yet another patch [was: XSP doesn't work: Cocoon 1.8.1-dev on Tomcat 3.3-dev]

----- Original Message -----
From: "Robin Green" <gr...@hotmail.com>
To: <co...@xml.apache.org>
Cc: <th...@ifrance.com>
Sent: Wednesday, November 01, 2000 10:57 PM
Subject: Re: XSP doesn't work: Cocoon 1.8.1-dev on Tomcat 3.3-dev


> Sorry, the patch that was submitted was buggy (always blame the submitters
> ;). I've fixed it now for Tomcat 3.1 at least. I'll look into 3.2 etc. at
> some later time.

I faced the same problem running Cocoon under Resin. Unfortunately, Resin
does not expose any "well-known" classpath attribute, so I just added an
ability to read classpath from Cocoon configuration file.
The patch follows:

org.apache.cocoon.processor.xsp.XSPProcessor.java:
218c218
<         classpath = System.getProperty("java.class.path");
---
>         classpath = new String();
218a219,223
>         Vector v = conf.getVector("classpath");
>         for (int i = 0, n = v.size(); i < n; i++) {
>             classpath += (String)v.elementAt(i) + File.pathSeparator;
>         }
>         classpath += System.getProperty("java.class.path");

I know this sucks, but we have to deal with the fact that there's no
standard way to obtain this information. I hope that Servlet2.3 spec will
address this issue. Till then, it would be a better idea to move all that
ugly code into a separate class, which will determine the servlet engine and
pull out of the servlet context as much useful information as possible.

Regards,
--
Sergei S. Ivanov  sergei_ivanov@object-tools.com
Object Tools, Moscow  http://www.object-tools.com