cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Date Tue, 02 Jul 2002 10:36:03 GMT
Andy Lewis wrote:

> If I have a custom transformer or generator that I wanted to deploy as a part of Coccon
block, can
> I using that interface? And is it an Avalon component or not? Are there adidtional steps
> just making it a cocoon block?

Sitemap components follow the avalon lifecycles but aren't exactly
'avalon components' because they are intrinsically tight to the cocoon

The question you should ask yourself when deciding if something is an
avalon component is:

  can I deploy my component in another avalon container? (say, Phoenix?)

If you look into org.apache.cocoon.components many of them are avalon
components that could be ported to other containers (even the
'programminglanguage' component, the core of the XSP engine, could be
decoupled from Cocoon and used elsewhere).

But a 'sitemap component', by design, isn't portable.

Also, another difference is that while avalon components are accessed by
role (thus behavior) and it's the container's concern to look it up,
sitemap components are accessed by both role and hint, thus it is *not*
the container's concern to look up the class (its concern is only to map
the hint to the classname, but control is re-inverted back).

On avalon-dev we had a pretty serious (and painful) discussion about
this and it has been suggested that Cocoon has been using Avalon for its
lifecycle (configurable, loggable, etc..) more than for its inverted
lookup capabilities. So Avalon has been used *and* abused by this

Used for moveable components and abused for those cocoon-specific

This said, it becomes obvious why we need two different deployment
mechanism: one for generic avalon components (think of Parsers, XSLT
Processors, Source Resolvers, Code Producers, etc..), and another for
cocoon-specific stuff (think of a web mail, a skin, a shopping cart,

The question was: even if these two things are different and live in two
different architectural layers, could the same code be used to implement

I've spent some time investigating this and I don't think Phoenix is up
to the job, because it is more biased toward having a single instance
per JVM.

Now I'm looking at Fortress and Merlin as possible future candidates.

I'll report back when I'm done.


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

View raw message