-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
Date: Fri, 30 Dec 2005 15:06:34 -0500
From: Vadim Gritsenko <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying component handling
Giacomo Pati wrote:
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.
service() method is already public, so I don't see any departure from
existing practice.
With 'the pure way' I mean getting rid of *ALL* Avalon artifacts
methodologies. This includes the Serviceable/service() stuff.
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
If goal is to write *less* code then this code won't have any checks at all
:)
I a pure setter based system you cannot determine when a component has
been fully initialized unless you have the initialize() method/Lifecycle
Carsten was mentioning (to signal the end of 'configuration' to the
component). With pure constructor injection you'll have that
again right in the constructor to check completness.
Regardless whether it is constructor or setter injection, checks can be
written same way anyway, so I don't see this as an argument.
Yes, the checks have to be made anyway, but see above.
As for final, that's actually and IMHO a downside: currently you can null out
all component references (and you can do that automatically with setter
injection! whoo-hooo! yeay!) and be *sure* that even if there are any leaks
in system, they are minimized. You can also be sure that you will get clear
NPE if somebody holding & using disposed component, instead of getting
undetermined behavior. So I'm -1 on final references for all of the above
reasons.
I don't see the reason to zap out the Logger, Configuration, Context. I
have to admit that I don't see component injections (as Carsten
suggested) as we do have too much dynamic in cocoon for many of our
components as they do not know which one they will depend upon before
consulting a Configuration or maybe the Context. My vision ATM would be
some kind of ServiceManager injection instead of multiple Components.
Of course this leads to looking up the needed services from that
ServiceManager but I don't see a way around it ATM.
(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 style.
Yep. Xdoclet, though, means pre-processing step - annotations are nicer in
this context.
I'm almost sure that Cocoon 2.2 will stay 1.4 compatible for another
year at least. So an approach with Xdoclet or qdox (see Maven2's
Mojo's) will be the only way to go ATM.
Anyway, unless we decide to get rid of the Avalon interfaces/Lifecycle
_completely_ this discussion is useless as Gianugo stated in his reply.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDtaDILNdJvZjjVZARAjbpAJ0SGm7NlmJ+QhrRMU5RxC6YrglZcACgl6M9
jho9rnXTUscLlDAVfiCFVV0=
=nUyY
-----END PGP SIGNATURE-----
