XSP Installation Proposal (was RE: WAR file)

[Berin Loritsch <bl...@infoplanning.com>]

"Stevenson, Chris (SSABSA)" wrote:

> > For adding .jar files... the order is important. Xerces
> > should be called
> > first due to reasons explained in the install docs.
> >
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xerces_1_0_3.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\fop_0_12_1.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\js.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\jstyle.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\svgv_0_8.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xalan_1_0_1.jar
> > set CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\cocoon.jar

Why is that?  If I don't use XSP, then everything else works fine by
letting the
servlet engine pull everything dynamically from the WEB-INF/lib
directory.
If cocoon.jar is not in the main CLASSPATH, XSP does not work.  To me,
this is a serious inhibition to making this thing work with an easy
install.

I experimented a little, and to get http://localhost/cocoon/hello and
http://localhost/cocoon/simple-page.xsp to work, I only needed to
put xerces, xalan, and cocoon in the main classpath.  When I tested
my FO page, I had to include the fop jar to make it work.

When I did not have cocoon.jar in the main classpath, everything else
auto-loaded fine--BUT, and this is a big but, XSP did not work.

Before you start responding to my next question with merits of
technology,
I want to preface that the question is in regards to servlet loading.
What
does XSP do that JSP doesn't that forces it to be in the main CLASSPATH?

What I mean by that is that the Tomcat JSP implementation does not
require
the JSP engine to be in the main CLASSPATH--it is automatically loaded.

If there is a technological reason why XSP cannot be reachitected to
allow
it to run in the auto-loaded version (cocoon.jar in WEB-INF/lib--not in
the main CLASSPATH), then I propose that we separate out the offending
classes into a separate jar file.  We would then have C2 create the
cocoon.jar
file _and_ an xsp.jar file.  The install instructions would require the
xsp.jar
file to be in the main CLASSPATH, and cocoon and all the other support
jars can remain auto-loaded.

I must say, the benifit of just dropping a directory into Tomcat (or any
other
servlet 2.2 compliant system) cannot be underestimated.  It will reduce
the
number of "I can't get this $(%@ working!" questions in the lists.

RE: XSP Installation Proposal (was RE: WAR file)

[David Duddleston <da...@i2a.com>]

There are 2 issues here from what I understand. One has to due with a compatibilty problem regarding xerces 1.0.3 and other xml packages that Tomcat uses (this will hopefuly be fixed soon and not be an issue). The other has to do with having the neccesary classes in the Tomcat class path for XSP pages to compile. Any class that is used within and XSP page will need to be included in the Tomcat path and not just the XSP specific classes. I'm not positive on this, but just drawing a conclusion based on my experience with cocoon 2 so far which has not been much.

-david



> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@infoplanning.com]
> Sent: Thursday, June 01, 2000 8:30 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: XSP Installation Proposal (was RE: WAR file)
> 
> 
> Berin Loritsch wrote:
> 
> > If there is a technological reason why XSP cannot be reachitected to
> > allow
> > it to run in the auto-loaded version (cocoon.jar in WEB-INF/lib--not in
> > the main CLASSPATH), then I propose that we separate out the offending
> > classes into a separate jar file.  We would then have C2 create the
> > cocoon.jar
> > file _and_ an xsp.jar file.  The install instructions would require the
> > xsp.jar
> > file to be in the main CLASSPATH, and cocoon and all the other support
> > jars can remain auto-loaded.
> 
> I know it looks like I'm feeding my own thread, but I had a thought
> about how such a change would impact C2 package heirarchy.
> If we were to create two files (cocoon.jar and xsp.jar), then all the
> jars in {package root}/lib that are necessary for runtime could be
> moved into /WEB-INF/lib.  The build.xml file would have to be
> modified to point to their new home, but it makes the installation
> even easier.  The 'dist' target would additionally copy cocoon.jar
> into the /WEB-INF/lib directory.
> 
> Even better: build.xml could have a new target--install-tomcat.
> It would package up the WAR file (including the jars in
> /WEB-INF/lib) and plop it into $TOMCAT_HOME/webapps!
> 

Re: XSP Installation Proposal (was RE: WAR file)

[Berin Loritsch <bl...@infoplanning.com>]

Berin Loritsch wrote:

> If there is a technological reason why XSP cannot be reachitected to
> allow
> it to run in the auto-loaded version (cocoon.jar in WEB-INF/lib--not in
> the main CLASSPATH), then I propose that we separate out the offending
> classes into a separate jar file.  We would then have C2 create the
> cocoon.jar
> file _and_ an xsp.jar file.  The install instructions would require the
> xsp.jar
> file to be in the main CLASSPATH, and cocoon and all the other support
> jars can remain auto-loaded.

I know it looks like I'm feeding my own thread, but I had a thought
about how such a change would impact C2 package heirarchy.
If we were to create two files (cocoon.jar and xsp.jar), then all the
jars in {package root}/lib that are necessary for runtime could be
moved into /WEB-INF/lib.  The build.xml file would have to be
modified to point to their new home, but it makes the installation
even easier.  The 'dist' target would additionally copy cocoon.jar
into the /WEB-INF/lib directory.

Even better: build.xml could have a new target--install-tomcat.
It would package up the WAR file (including the jars in
/WEB-INF/lib) and plop it into $TOMCAT_HOME/webapps!