RE: [picocontainer-dev] FactoryAdapter patch
Jörg Schaible <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Paul,
________________________________
From: Paul Hammant
Sent: Thursday, April 24, 2008 8:26 AM
Subject: Re: [picocontainer-dev] FactoryAdapter patch
So take a look at http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/src/test/org/picocontainer/DefaultPicoContainerTestCase.java
Everything from Swede on down, is new in the last few days.
These two demonstrate the usage of the new ComponentAdapter method that references the type you're injecting into.
testThatComponentCanHaveAProvidedDependency()
testThatComponentCanHaveAProvidedDependencyViaConstructor()
These two might be more like what Jörg is suggesting, in that they are behaviors that happen after injection. ...
testThatComponentCanHaveAProvidedDependencyViaDecoratorBehavior()
testThatComponentCanHaveAProvidedDependencyViaFieldDecoratorBehavior()
It is entirely possible that what I committed on Weds morning was wrong. "Just because we can does not mean we should".
The fellow on the user list (Peter Karich) might be just as pleased with the behavior/decorator route.
Thoughts?
________________________________
Yep. The last two examples do what I had in mind. However ... I am not sure if this is good idea either. If you use FDI instead of CDI the example simply fails, because the FI would miss the Swede dependency. From DI PoV the SwedeDecorating is a bad hack, since it provides an "undeclared" dependency.
Originally I had a ComponentFactory in mind that simply adds the logger to the provided parameters (note, the CF knows already the implementatopn type). But that's not working, since it would imply that either all components declare a dependency to a logger or all InjectionFactories can ignore superfluous parameters. I'd prefer the second option though. In combination with a mechanism to flag the "consumed" parameters. That way we could also chain the InjectionFactory impls and support hyprid components.
Concering the API change you're right, it's more internal. We did such a change between Pico 1.0 and 1.1 also. Nevertheless I'd opt for the right thing (TM). :)
- Jörg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email