Thanks...got 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 steps >> beyond 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 interfaces. > > 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 > 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 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, >etc..). > > 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 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. > > Stefano. > > > > --------------------------------------------------------------------- To >unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- "The heights of genius are only measurable by the depths of stupidity." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
