cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: cocoon and JServ repositories : severe flexibility problem
Date Fri, 03 Mar 2000 23:30:34 GMT
Sorry for the delay.

Fabien Campagne wrote:
> Hello,
> I tried to send this through the bug tracking system but the
> request did not go through (the robot rejected the submission
> because the component field was not selected, there is no
> value to select for cocoon!
> Please see )

It's fixed now.
> I am looking at the feasability of mixing Java servlets with Cocoon/XSP.
> We have a web service built with the servlet API that we would need
> to extend with XSP pages. During development, we need the ability to
> compile and execute XPS pages which use code defined in (a) package(s) stored
> in the JServ repository. The package is there because several developers
> work independently on changes to the package wich are isolated in different
> servlet zones. The final product is built of a combination of these changes.
> XSP will not compile and execute pages that use the packages referenced
> in the JServ repository (I configured the Cocoon servlet for every zone
> used for development): the compilation and execution of pages use the
> default classpath (property java.class.path). This makes impossible for us
> to develop XSP pages which rely on Servlet packages which are still in
> development (this is an evolving product, so these packages are likely to
> remain in development for a while). Moving the packages in the global
> classpath allows the XSP compilation/execution, but breaks the Jserv
> repository feature so useful at development.

It also imposes security problems. Ricardo, what do you suggest? How
hard is this to fix?

> To fully support the JServ repositories, Cocoon/XSP should build the
> classpath for compilation and execution from the JServ properties of
> the zone in which cocoon is being executed.
> As an example of the previous problem, consider our development
> environment:
> The classpath contains several classes used by every developer
> change and unlikely to change often:
> CLASSPATH=${CLASSPATH}:/usr/local/jsdk/jsdk.jar
> CLASSPATH=${CLASSPATH}:/usr/local/jdbc/
> CLASSPATH=${CLASSPATH}:/usr/local/jserv/lib/ApacheJServ.jar
> CLASSPATH=${CLASSPATH}:/usr/local/jserv/lib/ApacheJServSSI.jar
> CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/edu.mssm.crover.representation.jar
> CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/edu.mssm.crover.util.jar
> CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/edu.mssm.crover.imports.jar
> CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/edu.mssm.crover.domain2d.jar
> CLASSPATH=${CLASSPATH}:/usr/local/cocoon/cocoon.jar
> CLASSPATH=${CLASSPATH}:/usr/local/cocoon/xalan.jar
> CLASSPATH=${CLASSPATH}:/usr/local/cocoon/xerces.jar
> CLASSPATH=${CLASSPATH}:/usr/local/cocoon/fop.jar
> CLASSPATH=${CLASSPATH}:/usr/local/jdk/lib/tools.jar
> my devlopment zone defines the following repository:
> #                         development Servlet Zone Configuration File
> repositories=/export/home/aegis/projects/scentral/baseline/scentral.jar
> repositories=/export/home/campagne/dev/rbdeservice.C021/edu.mssm.crover.webservices.rbde.jar
> The package scentral contains classes that are shared among our servlet-
> based web services while rbdeservice is one such a service.
> Both packages evolve as the web services need to be developed (scentral
> hopfully at a slower rate that any web service package).
> rbdeservice.jar is taken from the change number 21, another developer
> is working at the same time on change 22 of the same service in a
> different zone.
> XSP pages need to be developed based on the package defined in change 21,
> while change 22 is being developed and tested on a different zone. This
> makes impossible to move rbdeservice.jar to the static classpath, and at
> the same time, forbid to develop XSP pages that reference rbdeservice.jar.
> The only work-around I see now is to configure a second JServ engine
> (actually a third, we use already one for dev. a second for production)
> that will have scentral and rbdeservice in the static classpath and will
> only be used for XSP pages development. Each time a change is integrated
> to the rbdeservice, the package will be updated in the configuration of
> the XSP Jserv engine. The whole process lacks flexibility and is convoluted
> for something which could be much simpler.
> Any suggestion would be appreciated.
> Fabien Campagne.
>  public void compile(String filename) throws Exception {
>     String repositoryName = this.repository.getCanonicalPath();
>       String fullFilename = repositoryName + File.separator + filename;
>     String[] compilerArgs = {
>       "-classpath",
>         repositoryName +
>         File.pathSeparator +
>         System.getProperty("java.class.path"),
>       "-O",

I don't think this is that easy. It's also a classloading issue. I
wonder if this can be JServ abstracted... if not.. we are in serious
trouble since this requires a Servlet API change!!!


Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message