cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robby Pelssers <>
Subject RE: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)
Date Tue, 19 Feb 2013 11:05:33 GMT
I agree on the fact that it's confusing to say the least when programming against the Java
API. And any simplifications on this aspect are welcome.


-----Original Message-----
From: Thorsten Scherler [] 
Sent: Tuesday, February 19, 2013 11:45 AM
Subject: Re: sitemap parameter in C3 (was Re: A generator with sitemap parameter in C3)

On 02/18/2013 02:50 PM, Thorsten Scherler wrote:
> On 02/11/2013 01:55 PM, gelo1234 wrote:
>> ...
>> So the setup(...) has access to sitemap parameters :) Why not
>> setConfiguration(..) ?
>> Does call:
>> this.setup((Map<String, Object>) configuration) strips off?/adds? 
>> some unwanted/additional data for sitemap-servlet framework ?
>> As i recall setConfiguration is for Java only (without
>> sitemap-servlet) Cocoon use and setup is for standard sitemap-servlet 
>> ? Is that correct ?
> No actually setConfiguration is for passing parameters from the 
> sitemap to the component e.g.
> The setup() will be called when the pipeline setup is called, I think 
> we should drop one since it is highly confusing.


     * Pass component specific configuration parameters to the pipeline
     * component in a generic way. This is useful in environments that
     * automatically assemble pipelines with their components and can't use the
     * components constructors or setters.
     * @param configuration The {@link Map} of configuration parameters.
    void setConfiguration(Map<String, ? extends Object> configuration);

     * The shared object map for this pipeline run.
     * @param parameters A {@link Map} of parameters that are available to all
     *            {@link PipelineComponent}s. This is a modifiable map
that can
     *            be changed by this pipeline component.
    void setup(Map<String, Object> parameters);

The main div is global vs. local map. Meaning the configure is intended to only configure
the specific component and not all. That makes sense in terms of the sitemap but in a pure
java pipeline hardly, well I can imagine a use case where it would be indeed very handy, but
first let us look on some java pipes.

I use something like the following to process some droidsTask in java with the help of c3:

 * LinkExtractorPipeline.
 * @param <T> T extends PipelineComponent  */ public class LinkExtractorPipeline<T
extends PipelineComponent> extends
        NonCachingPipeline<SAXPipelineComponent> {

    private static final Logger logger =

    private LinkExtractorTransformer linkExtractorTransformer;
     * LinkExtractorPipeline.
    public LinkExtractorPipeline() {
        linkExtractorTransformer = new LinkExtractorTransformer();
    public void setup(OutputStream outputStream, Map<String, Object>
parameters) {
        if (outputStream == null) {
            throw new SetupException("An output stream must be passed.");
        try {
            this.addComponent(new XMLGenerator((InputStream) parameters.get("src")));
            this.addComponent(new XMLSerializer());
            super.setup(outputStream, parameters);
        } catch (Exception e) {
            String message = "There were a problem setting up the pipeline.";
            logger.error(message, e);
            throw new SetupException(message, e);

     * @return outLinks
    public List<String> getOutLinks() {
        return linkExtractorTransformer.getOutLinks();

Then I call it from my java code like

LinkExtractorPipeline<SAXPipelineComponent> pipeline =
                new LinkExtractorPipeline<SAXPipelineComponent>();
        OutputStream output = new BufferedOutputStream(new ByteArrayOutputStream());
        // pass parameter to the pipeline
        Map<String, Object> parameters = new HashMap<String, Object>();
        parameters.put("src", task.getContentEntity().getContent());
        pipeline.setup(output, parameters);
        try {
        } catch (Exception e) {
            logger.error("Could not excecute pipeline.", e);
            throw new DroidsException(e);

Now the main difference to the usage from within the sitemap is that you cannot create your
own components like in java and configure them as you please.

However imagine the above LinkExtractorPipeline as pseudo sitemap config:

<map:pipeline id="linkExtractorPipeline">
      <map:match pattern="**"> -> we do not have the concept of matcher in the java
        <map:generate src="{droids:content}" />
        <map:transform type="linkExtractorTransformer"/>
        <map:serialize type="xml"/>

Now since we have the config done in the same class we could do something like <map:pipeline
id="linkExtractorPipeline" /> and then simply use spring to link back to LinkExtractorPipeline.class

However the other way around should as well be possible. Imagine we see the sitemap as simple
pipe config store, then I could simplify the above code to something like:
LinkExtractorPipeline<SAXPipelineComponent> pipeline = sitemap.getPipeline("linkExtractorPipeline");
and use the pseudo sitemap config instead of the java code LinkExtractorPipeline (leaving
along the matcher problematic).

The basic problem is that the concept of matcher and pipeline is a bit different in java vs
sitemap pipeline. Originally the main purpose of the pipeline element were to group certain
matches out of caching reasons. The matches however decide which part of the code will be
called, but basically you can call the pipe as much as you want. In java that is not true.
A pipe is disposable, once used it cannot be called again.

I personally would love to see that sitemap pipe and java pipe are the same (better said following
the same concept). Basically the java pipes would adopt the concept of matcher and be reusable
not disposable.


Regarding the original setup vs. setConfiguration maybe renaming setConfiguration to configure(...)
makes more sense and encourage to use the configure method for simple configuration.

If I recall the NekoGenerator modification I could have as well implemented a setDefaultEncoding()
and force the config into spring, however that would loose the ability to change it in a specific


Thorsten Scherler <> codeBusters S.L. - web based systems <consulting,
training and solutions>

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message