Wow, a long and fun thread ;)
Seem like most want to migrate away from the Avalon interfaces for
component handling and that some (I'm included), in the long term, want
to move away even from ECM++. IMO, with all communities that specializes
on containers, building containers should be outside the scope of
Cocoon. Of course we have to maintain ECM++ for back compability, but
hopefully as an optional block.
So the only remaining questions are where we want to go and how to get
there ;)
How
---
Concerning how to get there, using the Spring (or other) bridges. as
Sylvain proposes, for user component handling does part of the job, we
should IMO encourage users to use a bridge rather than ECM++ for new
development. Still the bridge in its current form, AFAICS, doesn't help
migrating the Cocoon core and the blocks to a more modern container.
One (yet unimplemented) feature with the block architecture is that one
can choose block manager at the block level and still exporting
components to other blocks. By using this and spliting the Cocoon core
into smaller blocks, migration to a modern container becomes easier as
we can migrate one block at the time.
Component management at the block level also removes the need to use sub
sitemaps with local component managers for modularization. This means
that we can depricate component containers at the sitemap level and thus
in the long run simplify the architecture and loosen the coupling
between conatiners and the sitemap engine.
We can also migrate to DI gradually within the blocks (and core) by
extending ECM++ with some DI mechanism as Carsten wants, but I agree
with those who fear mixed models. If we go that way, we should have a
clear idea where we want to go.
What
----
While we, IMO, shouldn't lock users to a specific container, we need a
common ground for development of the core and the most important blocks.
I have to little knowledge about Spring, Pico etc to have any opinion
yet. But for injection strategy I would prefer setter injection. Citing
Berin:
Setter Injection
---------------
Familiar JavaBean style interface, natural to many Java developers, and
> easy to use introspection based tools. Encorages failsafe design so that
> almost all components are optional. In short, the absense of other
> components cause the bean to work with diminished capacity. An example
> is the DataSource object from the SQL package. In fact, that component
> would work out of the box in this type of environment.
Constructor Injection
---------------------
Very robust design, less familiar to many Java developers, but natural
> enough. Encourages tight encapsulation and failfast design so that
almost
> all components are required. In short, the absense of other components
> can cause the component to crash. Examples include just about any
> unmodifiable POJO object.
Here it is the "failsafe design" aspect that I find most important. One
of the long term goals with the blocks system is to allow for hot
deployable and updateable blocks. While hot deployabillity no doubt is
complicated and even might be to complicted for some kinds of blocks, it
is a very large advantage not least for getting development interactive.
Also OSGi helps a lot in this area.
Now, in a dynamic environment, the "failfast design" of constructor
injection isn't atractive at all anymore, as the assumption that all
components are constructed once and for all at startup isn't valid
anymore. Also, the new (and very prommissing) declarative services from
OSGi R4, supports setter injection but not constructor injection.
Declarative services is a standardised component container for OSGi
which is designed with dynamic component creation, update and
destruction, in mind. IBM have recently donated the reference
implementation to Eclipse.
As others have noted, we will need to support the use of a sevice
manager even in the future, dynamic builders like the sitemap engine
cannot just be injected with all the components they need.
I agree with Carsten that we should migrate towards using thread safe
components and factories everywhere. This is needed in the OSGi
environment as the OSGi service architecture assumes singletons and
factories. This is a separate concern that we can start to work on
immediatly. As long as we use Avalon interfaces, respecting the
contracts is however IMO more important than saving a few keystrokes, so
we shouldn't change defaults.
We also need to rethink configuration for components in blocks. We need
two levels, one "deploy time configuration" level, that is on the user
level and probably is property based, and one "wiring" level that is
statically declared within the block and takes care of implementation
details. OSGi already have a mechanism for this where the declarative
services configuration is used for the wiring level and the
configuration service for the deploy time configuration.
--- o0o ---
Summarizing my opinions: Users should be able to use any container.
Blocks and a more fine grained modularization of the core gives the
possiblity to migrate to a new container in steps. We need a common
strategy for core and important blocks. Setter injection is more natural
for a dynamic environment. We should start migrating towards threadsafes
and factories. Two levels of component configuration are needed.
Building component containers is outside the scope of Cocoon.
/Daniel
