| |
Cocoon components in PageBox framework
Patches
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
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
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
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.
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.
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
- Presentation of Cocoon/SOAP integration
- Installation guide
Installation
Constellations
Versions
Demo
Publisher
Mapper
Cocoon/SOAP
Security
Configurator
J2EE version
Embedded version
Diskless version
Contact:support@pagebox.net ©2001-2004 Alexis Grandemange
Last modified
|