cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [RT] Simplifying component handling
Date Fri, 30 Dec 2005 19:45:10 GMT
Hash: SHA1

On Fri, 30 Dec 2005, Vadim Gritsenko wrote:

> Date: Fri, 30 Dec 2005 14:21:07 -0500
> From: Vadim Gritsenko <>
> Reply-To:
> To:
> Subject: Re: [RT] Simplifying component handling
> Carsten Ziegeler wrote:
>>  Gianugo Rabellino wrote:
>> >  I'm definitely not a fan of constructor injection, exp. when we
>> >  consider how (way too) often we resorted to inheritance in Cocoon
>> >  components. Now, while interface injection is clearly out of fashion,
>> >  sticking with Avalon/Excalibur also means that it would be difficult
>> >  to get around the container (e.g., how do you release components with
>> >  your approach? I assume Excalibur still kinda needs that).
>>  Yes, Excalibur still needs it - but it's easy. Bascially, you "emulate"
>>  the service() method on construction of the object and then you
>>  "emulate" the dispose method when destroying the object. Everything our
>>  ecm++ needs to know is there. As I said, I've done this in Fortress and
>>  we can use that code in ecm++ as well.
>>  And we could implement setter injection with some kind of auto wiring as
>>  well. It's not really that harder. But using setters again requires to
>>  code more than using a constructor.
> I'm with Gianugo on this one - I'd better have setter injection instead of 
> constructor injection.

Actually the problem I see with setter injection is that you normally 
will open up the setter method (make it public) to your 
configurator/instatiator and thus to everybody else. Now, don't tell my 
'you can write some IF satements to prevent that. The reason for a 
change as Carsten stated was 'I want to write less code'.

The constructor injection IMO allows you to make your member variable 
holding the injected objects final as well as checking whether the 
component is correctly constructed (especially if it needs a 
Configuration object) in the constructor itself. So for me constructor 
injection (and only constructor injection, no mixes allowed) is much 
more robust over setter injection and needs less code.

For these issues I'm more in favor of constructor injection (if we have 
the vision to go the pure way) than setter injection.

> In *addition* to setter injection, ecm++ could also recognize annotations (if 
> running under jdk 1.5).

I do not exclude annotations be it 1.5 annotations or other xdoclet 

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message