Cocoon components in PageBox framework

Patches

1. Why?

   With PageBox, Cocoon and Xerces are loaded by PageBox class loader and must retrieve resources such as XML and XSL files from Presentation archives. It means using getResourceAsStream rather than file access as promoted with Servlet 2.2 specification. As this model (delegating file access to current class loader) is better it should generalize. However Servlet 2.2 is not so old - Cocoon and Xerces existed before - and these products are designed to also run outside an Application Server.

   Both Cocoon and Xerces isolate file access in a small set of classes, so there are only few patches. Note that we didn't cover all possible uses of these libraries in JSPservlet Version 1.0.4. We insure we were able to run:

   • the samples
   • Network processor demo

2. Xerces

   File: org.xml.sax.InputSource.

   The SAX parser will use the InputSource object to determine how to read XML input. If there is a character stream available, the parser will read that stream directly; if not, the parser will use a byte stream, if available.

   The patch tries to get a resource input stream from the JSPservlet class loader based on the systemId. Beside the fact we need it to support archive publishing and deployment, the patch enhances the performance as the resource is cached in memory.

   Source: org.xml.sax.InputSource

   Archive: InputSource.jar

   Patched version of Xerces: 1.2. The patch should also be valid with Xerces 1.3

3. Cocoon

   Files: org.apache.cocoon.Utils, org.apache.cocoon.processor.xsp.language.java.XSPClassLoader, org.apache.cocoon.processor.xsp.language.java.XSPJavaProcessor.

   org.apache.cocoon.Utils patch modifies getLocationResource methods and uses classloader.getResource as suggested in comments

   org.apache.cocoon.processor.xsp.language.java.XSPClassLoader patch modifies XSPClassLoader to fit with JSPservlet class loaders. This patch can change with next PageBox versions.

   org.apache.cocoon.processor.xsp.language.java.XSPJavaProcessor is responsible to build XSP compilation request. The patch sets the classpath based on JSPservlet configuration.

   Source: cocoonPatchSrc.jar

   Archive: cocoonPatch.jar

   Patched version of Cocoon: 1.8.2.

Network processors

1. cocoonSupport/CocoonNetwork.java

   CocoonNetwork.java is an HTTP processor.

   By default, CocoonNetwork.java expects to find an XML element named WebServiceHeader under the root element like this:

   <WebServiceHeader>

   <Url/>	Web service URL	mandatory
   <TimeToComplete/>	After TimeToComplete milliseconds the request is cancelled	optional (default 2000)

   </WebServiceHeader>

   You can change its behavior by overiding its processQuery method.

   By default, CocoonNetwork.java returns a message:

   <Reply>
      <Request>
         Message received by CocoonNetwork.java
      <Request/>
      <Response>
         Message returned by the Web service or Error message
      <Response/>
   <Reply/>

   You can change its behavior by overiding its processResponse method.

2. cocoonSupport/CocoonSOAP.java

   CocoonSOAP.java is a SOAP processor.

   By default, CocoonSOAP.java expects to find an XML element named WebServiceHeader under the root element like this:

   <WebServiceHeader>
   

   <Url/>	Web service URL	mandatory
   <TargetObjectURI/>	Name the SOAP service is registered with	mandatory
   <Method/>	Name of the method to invoke	mandatory
   <TimeToComplete/>	After TimeToComplete milliseconds the request is cancelled	optional (default 2000)

   </WebServiceHeader>

   You can change its behavior by overiding its processQuery method.

   By default, CocoonSOAP.java returns a message:

   <Reply>
      <Request>
         Message received by CocoonNetwork.java
      <Request/>
      <Response>
         Message returned by the Web service or Error message
      <Response/>
   <Reply/>

   You can change its behavior by overiding its processResponse method.

   Current (Version 1.0.4) CocoonSOAP.java is only able to call methods with a signature
   Element myMethod(Element) where Element is a DOM Element.
   Though this model is the most concise and extensible one, it doesn't use very well SOAP features.

   You can implement a SOAP processor using CocoonSOAP.java as a template. We would be happy to make it downloadable on this site.

3. Packaging

   Source: cocoonSupportSrc.jar
   Archive: cocoonSupport.jar

Loopback servers

We provide these servers for convenience.
loopback.loopbackServlet.java is a servlet that returns what it received with a text/xml type.
loopbackSOAP.java is a SOAP server with a method Element getDocument(Element doc). It expects to receive a DOM element and returns it. It must be registered with a command:

java org.apache.soap.server.ServiceManagerClient
rpcrouter_url deploy DeploymentDescriptor.xml

where DeploymentDescriptor.xml was defined like this:

<?xml version="1.0"?> <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
    id="urn:loopbackSOAP">
  <isd:provider type="java"
    scope="Request"
    methods="getDocument">
    <isd:java class="loopback.loopbackSOAP"/>
  </isd:provider>
  <isd:faultListener>org.apache.soap.server.DOMFaultListener</isd:faultListener>
</isd:service>

These servers are primarily designed to be used with the demo we present below.

Sources: loopbackSrc.jar
Archive: loopback.jar

Demo

The demo uses an XSP file, either CocoonNetwork or CocoonSOAP processor and a Cocoon formatter selected in the processor (in processResponse, a method that you can override). It is the simplest application you can implement. It contains:

first.htm	An HTML form to fill the request
demo.xml	The XSP producer

Archive: demo.jar

Usefull links

1. Presentation of Cocoon/SOAP integration
2. Installation guide