cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Simplifying component handling
Date Wed, 04 Jan 2006 11:01:11 GMT
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 ;)


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.


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 

> 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 
 > 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.


View raw message