cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Lewis" <>
Subject Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Date Wed, 03 Jul 2002 01:41:24 GMT it...I think.

I'll be interested to hear how the research comes out....

> 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
>> beyond just making it a cocoon block?
> Sitemap components follow the avalon lifecycles but aren't exactly 'avalon components'
> they are intrinsically tight to the cocoon interfaces.
> The question you should ask yourself when deciding if something is an avalon component
>  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
> 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
> suggested that Cocoon has been using Avalon for its lifecycle (configurable, loggable,
> more than for its inverted lookup capabilities. So Avalon has been used *and* abused
by this
> project.
> Used for moveable components and abused for those cocoon-specific
> components.
> This said, it becomes obvious why we need two different deployment mechanism: one for
> avalon components (think of Parsers, XSLT Processors, Source Resolvers, Code Producers,
> 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 both?
> I've spent some time investigating this and I don't think Phoenix is up to the job, because
> 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.
> Stefano.
> --------------------------------------------------------------------- To unsubscribe,
> For additional commands, email:

"The heights of genius are only measurable by the depths of stupidity."

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

View raw message