cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Interpreted sitemap
Date Wed, 07 Nov 2001 22:15:21 GMT
On Wed, 07 Nov 2001 10:21:59 +0100, Sylvain Wallez <>

> > One of the my requirements for this re-implementation is to allow
> > things other than SAX events to flow on the pipeline. I'm specifically
> > thinking of Java objects that could represent the incoming HTTP
> > request as an object, for unorthodox types of processing. Of course
> > the interfaces of the components in the pipeline have to be compatible
> > for such an approach to work.
> Could you explain in more detail these unorthodox types ? Can't this be
> solved by a custom Environment implementation and/or a Generator ?

I don't think it can, but maybe you can prove me wrong.

What I need is the ability to have a custom generator that reads the
input HTTP request, and constructs a Java object out of it.

An example is when the SOAP message is actually SOAP with
attachments. In that case I'd like to pass on the pipeline a JAXM
SOAPMessage object, together with the output SOAPMessage object. The
transformers will operate on incoming message and construct the
outgoing message, as the processing flows through the pipeline. The
trick is I still want to make use of the great XML processing
capabilities of Cocoon, and don't want to reinvent a new framework for

> > My thoughts were to take the Ant XML->Java conversion engine, extend
> > it to use the SAX2 API, and create Avalon components that represent
> > the pipeline. The Ant engine is indeed a very simple, yet powerful and
> > extensible way to create a hierarchy of Java objects from an XML
> > document.
> Didn't know about this Java/XML stuff in Ant. I will look at it.

It's a very simple way to hook up Java objects. Essentially each XML
element is represented by a Java class. For each child element of this
element you need to implement an add<ChildElementName>(<ClassName>)
method. For each attribute understood by your element, you need to
implement a set<AttributeName>(<type>) method. Now you do have some
constructs by which you can add to an element _any_ element you like,
which is very useful when you want your element to support arbitrary

The Ant engine starts reading the XML file and during the SAX parsing
it creates the necessary objects and hooks them up as needed. After
the whole Java tree gets constructed this way, it will invoke the
execute() method on the topmost object. This triggers the execution of
the build.

In Cocoon's case, the invocation will happen when a request is
received. And instead of doing a build, the topmost object will invoke
the match objects. When one match object succeeds, its corresponding
pipeline is executed.

The nice part about this is that you can hookup any object in the
sitemap, as long as it follows a well defined API. The objects in the
pipeline should be Avalon components, so they can take advantage of
the pooling and other features from Avalon.

I've successfully implemented a similar framework based on the
concepts mentioned above. Check it out at:

Take a look at the MatcherSet, Matcher and MatcherTest classes and how
they are use from the ActionTask.

> > Could you describe a bit your approach?
> Well, I wanted the structure of this to be stabilized, at least from my
> point of view, before committing it into CVS. This should be in a few
> days, or the beginning of next week. If you can't wait, I can open a
> scratchpad area and put it in, but with no warranty of what comes in ;)

Yes, I would definitely be interested in taking a look at it. It
doesn't need to compile necessarily either ;-) So if you can put it in
a scratch-pad area that would be great!

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

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

View raw message