cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] Another step to blocks: Application container support
Date Sat, 12 Mar 2005 13:19:58 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> +1. That was one of the concerns I expressed when seeing more and more 
> features going into the core container. We should stick it to the 
> well-known old ECM behaviour (plus a few additional bonuses like proxied 
> poolable), and not try to extend it up to being a full-blown POJO container.
Yes, that's my idea today as well :) (I must admit that my initial
motivation for creating our own core was exactly that: build a
full-blown container...but now I know that this would be the wrong

> <SNIP/>
> +1 as well. Such listeners could be declared a bit like in CForms, and I 
> currently see 4 types of listeners :
> - on-enter (entering a sitemap)
> - on-pipeline-built (a pipeline has been built, but not yet executed)
> - on-execute-pipeline (the previously built pipeline is executed)
> - on-leave (going out -- needs to have the information of success, no 
> match or exception)
> on-pipeline-built and on-execute-pipeline are IMO needed to handle the 
> strict separation of these phases in the case of internal ("cocoon:") 
> processing.
Hmm, yes, might be - I have to think about it.

> Back in fall 2004 I started prototyping an implementation of an Avalon 
> component with Spring. Although technically feasible, this proved to 
> require some work to be able to merge both configuration styles in a 
> single file or convert Avalon-style xconf into Spring-style bean 
> definitions. A lot of DCC-specific code to write and maintain.
> Now we actually don't have to mix them, but simply use the hierarchical 
> nesting capabilities of both our containers and most (if not all) DCCs.

> Yes. Actually most of what is needed for this is a set of bidirectional 
> adapters between ServiceManager and the equivalent interfaces in DCCs. 
> That would allow for a DCC to be a parent of our core service manager 
> and reciprocally.
> A component will then be managed by the appropriate CC (component 
> container) type, and be available in that CC and all its children, 
> whatever their kind. Proxied poolables is probably key to allow this as 
> AFIACS not all DCCs have explicit release().
Yes ;)

> Yes. Since DCCs don't have a complex lifecycle as Avalon, the Context 
> should be available as a component, and not only through a separate 
> lifecycle interfaces.
Yes, I started already with the Settings object which is not a map (like
the context), but allows typed access to the information.

> Another very Cocoon-specific component is the SourceResolver. Since now 
> manage our classloaders, we could benefit from the 3rd constructor 
> parameter of URLClassLoader which is a URLStreamHandlerFactory.
> That would give access to the rich set of Cocoon-defined protocols using 
> Can you imagine writing "new 
> URL("cocoon://blah").openStream()"? That would be cool :-)
Yes, indeed - it would make all the source resolving stuff obsolete. Now
that will be fun to explain it to the users.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message