Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Guys, remember the real-blocks container story? Two reasons led to the
choice of OSGi: there are existing implementations, and it stopped the
endless discussions about what the container API should be.
We have exactly the same here. "why not this or that" and "I don't need
it but you can implement it" lead nowhere. NIH syndrome at work.
Cocoon's goal is not about containers, but about components. Cocoon was
one of the first component-oriented frameworks, but times have changed!
Yes, so why not throwing ECM++ away and use an existing container? We
can provide an Avalon compatibility bridge for nearly any existing
container.
Incidentally, I had just started to write a implementation of the Avalon
lifecycle as a Spring BeanFactory when you committed the Spring bridge.
The current bridge allows Spring to run in an Avalon container, whereas
what I had started was the other way around, i.e. an Avalon container
within Spring. Need to dig in my HD although I'm not sure I still have it...
I don't want to build an own container in Cocoon, but
currently using an existing one for the core has been veto'd several
times, so we have to stick with ECM++.
What has been vetoed is turning ECM++ to a DI container, which is not
Cocoon's goals and allow confusing mixed models to develop components
(opposed to writing components _either_ the Avalon way _or_ the POJO way).
But making this more useful is
also veto'd. Hmm. And as we can't come up with a good solution (being it
using an existing container or improving our own), we simply tell the
users to use whatever they think is right - as we don't know it.
Uh? I don't follow you here.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
