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]
