Re: cocoon and JServ repositories : severe flexibility problem

[Stefano Mazzocchi <st...@apache.org>]

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 http://xml.apache.org/bugs/enter_bug.cgi?product=Cocoon )

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/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",

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!!!

Hmmmm...

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

Re: cocoon and JServ repositories : severe flexibility problem

[Pierpaolo Fumagalli <pi...@apache.org>]

Fabien Campagne wrote:
> 
> Stefano Mazzocchi wrote:
> 
> > > Fabien Campagne wrote:
> 
> > > 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
> 
> > 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!!!
> 
> I quickly realized that this solution was not enough. The solution
> requires to obtain the classes from exactly the same class-loader
> as JServ does. If not, the static variables defined in the servlet
> environment will not be available to XSP.
> I experimented an ugly hack: patch JServ to obtain the classloader,
> and patch cocoon to install JServ's classloader instead of the
> one used normally. Then you add the cocoon repository to the JServ
> repository for the zone that serves both servlets and XSP.
> I also changed the java.class.path to cocoon.java.class.path to make
> it distinct from the CLASSPATH of the jserv engine that runs Cocoon.
> 
> I did not want to obtain the whole cocoon distribution and compile
> it so I just recompiled the XSPJavaProcessor.class file and updated
> it in the jar.
> 
> The results were mitigated. With cocoon 1.6, I obtained the desired
> behabiour but also some ClassNotFound exceptions the second time
> I was accessing the pages. I guess there is a relationship to the
> caching mechanism that I do not  know. With Cocoon 1.7, I obtained the
> ClassNotFound exceptions immediately.
> 
> Of course, because this was just a tentative, I did not consider security
> issues at this step and I cannot offer a clean design. I just thought you
> might be interested.

I think I understand where the problem resides, and how the classloader
is implemented in JServ... I'm considering right now XSP for Cocoon 2.0,
and starting to approach the problem. I'll let you all know what are my
feelings on this, as soon as I have some working "pseudocode"... :)

	Pier

-- 
--------------------------------------------------------------------
-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org>    <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------

Re: cocoon and JServ repositories : severe flexibility problem

[Fabien Campagne <ca...@inka.mssm.edu>]

Stefano Mazzocchi wrote:

> > Fabien Campagne wrote:

> > 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

> 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!!!


I quickly realized that this solution was not enough. The solution 
requires to obtain the classes from exactly the same class-loader 
as JServ does. If not, the static variables defined in the servlet
environment will not be available to XSP.
I experimented an ugly hack: patch JServ to obtain the classloader,
and patch cocoon to install JServ's classloader instead of the 
one used normally. Then you add the cocoon repository to the JServ
repository for the zone that serves both servlets and XSP.
I also changed the java.class.path to cocoon.java.class.path to make
it distinct from the CLASSPATH of the jserv engine that runs Cocoon.

I did not want to obtain the whole cocoon distribution and compile
it so I just recompiled the XSPJavaProcessor.class file and updated
it in the jar.

The results were mitigated. With cocoon 1.6, I obtained the desired 
behabiour but also some ClassNotFound exceptions the second time 
I was accessing the pages. I guess there is a relationship to the 
caching mechanism that I do not  know. With Cocoon 1.7, I obtained the 
ClassNotFound exceptions immediately.

Of course, because this was just a tentative, I did not consider security
issues at this step and I cannot offer a clean design. I just thought you
might be interested.


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 -----------------