You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bart Molenkamp <b....@bizzdesign.nl> on 2005/07/05 17:00:53 UTC

Dependency injection in Cocoon 2.1

Hi,

I want to get rid of the Avalon interfaces in my code. Is there
something like dependency injection (e.g. setter injection or
constructor injection - similar to Spring framework) possible using ECM?
(ECM is the component engine of Cocoon, right?)

I couldn't find anything, so I started a little "experiment" on my own.
I wrote a class ComponentHandlerImpl. This class implements all the
Avalon lifecycle interfaces. For each component, I define this class as
my default class:

<role name="com.bizzdesign.components.Hello" shorthand="hello"
  default-class="com.bizzdesign.components.ComponentHandlerImpl"/>

<role name="com.bizzdesign.components.World" shorthand="world"
  default-class="com.bizzdesign.components.ComponentHandlerImpl"/>

The ComponentManagerImpl class also implements Configurable, and uses
that configuration to get the name of the target class. It creates a new
instance of that class, and uses the configuration too set dependencies.
Something like:

<hello target-class="com.bizzdesign.components.HelloImpl">
  <property name="world" ref="com.bizzdesign.components.World"/>
</hello>
	
<world target-class="com.bizzdesign.components.WorldImpl">
</world>

These are used to set dependences. The ComponentHandlerImpl will lookup
the source resolver (using the regular service manager), then invoke
setWorld() on the HelloImpl instance with the resolved World instance as
an argument (just an example).

I could easily add similair methods to replace Initializable,
Disposable, Contextualizable, ...

Positives:
- cleaner code, not dependent on any Avalon interfaces. Thus reusable in
other environments, probably in the 2.2 environment too.
- allows for (unit) testing.
- user interception for components is possible (e.g. one could introduce
an AOP framework or something similair).
- Avalon is still working

Negatives:
- When resolving the Hello component, we get an instance of
ComponentHandlerImpl. I have to call getTarget() to get the actual
component.

Is something (which is not much in code) worthy to add to Cocoon? Or did
I overlook some feature that already handles this?

Bart.