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
approach).
> <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.
>
Yepp.
>
> 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
> java.net.URL. 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
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
