cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Interpreted sitemap
Date Thu, 08 Nov 2001 15:21:23 GMT

Ovidiu Predescu a écrit :
> 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
> this.

What about storing the object in the objectModel or in a Request
attribute ? This makes it available to every element of the processing
chain. Or did I miss something ?

> > > 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
> elements.
> 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.

I've looked at it : it's nice, but doesn't exactly correspond to what I

Firstly, the new TreeProcessor reads sitemap.xmap in a
so-easy-to-process Avalon configuration, while Ant is entirely
SAX-based. However, it would be good to have a Configuration2JavaBean or
something like that. Have to think about it.

Secondly, and more important : the tree of processing objects isn't
built directly from the XML tree. The sitemap file is used to build a
tree of NodeBuilder objects, that in turn create the actual
ProcessingNodes that will process the environment. This allows the
builders to choose between different implementations of ProcessingNode
depending on the environment : use of threadsafe or single-threaded
components, disctinction between PreparedMatcher and Matcher, etc. This
is key for maximum speed at process time.

> 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.

I'll do it.

> > > 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!

Ok, I've put it in $cocoon/scratchpad. It compiles, but is largely
incomplete and "subject to change without notice" (TM) : I'm not fully
satisfied by the CM stuff I've written.

Comments welcome :)


> Thanks,
> --
> Ovidiu Predescu <>

Sylvain Wallez
Anyware Technologies -

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

View raw message