cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabien Campagne <campa...@inka.mssm.edu>
Subject cocoon and JServ repositories : severe flexibility problem
Date Mon, 28 Feb 2000 01:56:23 GMT
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 http://xml.apache.org/bugs/enter_bug.cgi?product=Cocoon )

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.

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/classes111.zip
CLASSPATH=${CLASSPATH}:/usr/local/jserv/lib/ApacheJServ.jar
CLASSPATH=${CLASSPATH}:/usr/local/jserv/lib/ApacheJServSSI.jar
CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/ecs.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}:${GLOB_JARDIR}/Acme.jar
CLASSPATH=${CLASSPATH}:${GLOB_JARDIR}/joe.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",
-- 
Fabien Campagne      -- Dept. of Physiology and Biophysics,   
phone: (212)-241-0860   Box 1218, Mount Sinai School of Medicine,
fax:   (212)-860-3369   One Gustave L. Levy Place,
---------------------   New York, NY 10029-6574 -----------------

Mime
View raw message