Pipeline Engine API

Hi,

I have a number of custom pipelines, which one gets run for a single
action is decided at runtime. I'm using the pipeline engine API to
create a processor definition (with the appropriate XPL URL as the
config input) for each request, i.e.

public String runPipeline(final String xplUri) {
    final ProcessorDefinition processorDefinition = new
ProcessorDefinition();
    processorDefinition.setName(new QName("pipeline",
XMLConstants.OXF_PROCESSORS_NAMESPACE));
    processorDefinition.addInput("config", xplUri);    
    final processor = InitUtils.createProcessor(processorDefinition);
    processor.createOutput("data");
    try {
        InitUtils.runProcessor(processor, new
CommandLineExternalContext(), pipelineCtx, LOG);
        DOMSerializer serializer = new DOMSerializer();
        PipelineUtils.connect(processor, "data", serializer, "data");
        serializer.start(pipelineCtx);
        Document document = serializer.getDocument(pipelineCtx);
        return document.asXML();
    } catch (Exception e) {
        ...
    }
}

I have the following questions / concerns:

1) Am I incurring a big overhead for each invocation?
2) Can I reuse / share the DOMSerializer?
3) Are processors like DOMSerializer thread-safe?
4) My pipelines will always have a single output called 'data' - is
using DOMSerializer the best approach here?
5) From looking at the source I see that ProcessorInputImpl etc are
Cacheable, does this mean I shouldn't be too concerned about creating
what amounts to the 'same' pipeline over and over again?



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Jonathan,

 > I have a number of custom pipelines, which one gets run for a single
 > action is decided at runtime. I'm using the pipeline engine API to
 > create a processor definition (with the appropriate XPL URL as the
 > config input) for each request, i.e.
 >
 > public String runPipeline(final String xplUri) {
 >     final ProcessorDefinition processorDefinition = new
 > ProcessorDefinition();
 >     processorDefinition.setName(new QName("pipeline",
 > XMLConstants.OXF_PROCESSORS_NAMESPACE));
 >     processorDefinition.addInput("config", xplUri);
 >     final processor = InitUtils.createProcessor(processorDefinition);
 >     processor.createOutput("data");
 >     try {
 >         InitUtils.runProcessor(processor, new
 > CommandLineExternalContext(), pipelineCtx, LOG);
 >         DOMSerializer serializer = new DOMSerializer();
 >         PipelineUtils.connect(processor, "data", serializer, "data");
 >         serializer.start(pipelineCtx);
 >         Document document = serializer.getDocument(pipelineCtx);
 >         return document.asXML();
 >     } catch (Exception e) {
 >         ...
 >     }
 > }
 >
 > I have the following questions / concerns:
 >
 > 1) Am I incurring a big overhead for each invocation?

Hard to tell for sure without doing some Java profiling.

You could optimize by skipping the creation of the Document, which can
be costly with dom4j. You would directly read the output with
something like this:

ProcessorOutput output = processor.createOutput("data");
TransformerHandler identity = TransformerUtils.getIdentityTransformer();
StringWriter writer = new StringWriter();
identity.setResult(new StreamResult(writer));
output.read(pipelineContext, identity);
return writer.toString();

 > 2) Can I reuse / share the DOMSerializer?

Yes, but not the PipelineContext object.

 > 3) Are processors like DOMSerializer thread-safe?

In general yes, but make sure you pass different PipelineContext
objects.

 > 4) My pipelines will always have a single output called 'data' - is
 > using DOMSerializer the best approach here?

See the option above.

 > 5) From looking at the source I see that ProcessorInputImpl etc are
 > Cacheable, does this mean I shouldn't be too concerned about creating
 > what amounts to the 'same' pipeline over and over again?

Caching behavior is tricky and processor-dependent. An XSLT
transformer will cache its compiled input stylesheet if possible. The
Pipeline processor will do the same for its input pipeline. But the
DOM serializer won't cache it's result, for example, although the HTTP
serializer will. "Possible" here means that there are identifiable
dependencies for the input. A trivial case of this is connecting a
Pipeline processor to a URL generator pointing to "file:/something" or
"oxf:/something". Check this FAQ entry for some more information:

   http://www.orbeon.com/ops/doc/home-faq#caching

-Erik

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws