Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.3
-
Fix Version/s: 2.0
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Environment:Not applicable
-
Number of attachments :
Description
I was thinking if PicoContainer could also provide some selective dependency injection i.e. if we have two objects of a similar kind, the object that needs to be provided to the Servlet should be nearest in hierarchy of inhereitance.
For example
If I have a interface Feature
And there is one implementation of Feature called OldFeature
And there is another implementation of Feature called NewFeature
Should an object called User require Feature, then automatically the NewFeature should be provided to it.
This should in someway solve the versioning problem.
Activity
Due to picocontainer's excelent design, it can be done with relatively little effort. To do that you would have to subclass the ComponentParameter class (http://svn.codehaus.org/java/picocontainer/trunk/container/src/java/org/picocontainer/defaults/BasicComponentParameter.java?rev=1988&root=picocontainer&view=auto) implementing your custom key -> implementation matching strategy.
If you are doing your assembly directly in Java you're done: just use your parameter class instead a stock one. If you use scripts for assembly you would have to persuade the container builder to use your own parameter class - it should be possible by subclassing the stock builders, but I'm not sure about their design details: I use a custom xml based builder (http://objectledge.org/viewcvs.cgi/Ledge/ledge-container/src/main/java/org/objectledge/pico/xml/), and a subclassed ComponentParameter while we are at it.
Rafal Krzewski
added a comment - Due to picocontainer's excelent design, it can be done with relatively little effort. To do that you would have to subclass the ComponentParameter class ( http://svn.codehaus.org/java/picocontainer/trunk/container/src/java/org/picocontainer/defaults/BasicComponentParameter.java?rev=1988&root=picocontainer&view=auto ) implementing your custom key -> implementation matching strategy.
If you are doing your assembly directly in Java you're done: just use your parameter class instead a stock one. If you use scripts for assembly you would have to persuade the container builder to use your own parameter class - it should be possible by subclassing the stock builders, but I'm not sure about their design details: I use a custom xml based builder ( http://objectledge.org/viewcvs.cgi/Ledge/ledge-container/src/main/java/org/objectledge/pico/xml/ ), and a subclassed ComponentParameter while we are at it. Jörg Schaible
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Affects Version/s | 1.1 [ 10307 ] | |
| Assignee | Joerg Schaible [ joehni ] | |
| Fix Version/s | 1.3 [ 11331 ] |
Is this addressed by the fixed PICO-165 ??
Paul Hammant
added a comment - Is this addressed by the fixed PICO-165 ?? No. We need a special Parameter implementation to select the "nearest". We will currently always have ambiguity.
Jörg Schaible
added a comment - No. We need a special Parameter implementation to select the "nearest". We will currently always have ambiguity. Rethink:
Just because NewFeature extends OldFeature does not mean it's 'nearer'.
I'm thinking that there is no change to Pico for this.
If one does not register OldFeature then it will not be a candidate for injection - there are so many ways to overcome this without a change to Pico's functionality.
Paul Hammant
added a comment - Rethink:
Just because NewFeature extends OldFeature does not mean it's 'nearer'.
I'm thinking that there is no change to Pico for this.
If one does not register OldFeature then it will not be a candidate for injection - there are so many ways to overcome this without a change to Pico's functionality. Michael Rimov
made changes -
| Affects Version/s | 1.1 [ 10307 ] | |
| Affects Version/s | 2.3 [ 14303 ] |
Michael Rimov
made changes -
| Fix Version/s | 2.3 [ 14303 ] | |
| Fix Version/s | 1.3 [ 11331 ] |
public FeatureUser ( Feature newfeature) {
}
... or ...
public FeatureUser ( @NewVersion Feature feature) {
}
.. in Pico 2.0.
Of course it requires your making a binding annotation or a doing USE_NAMES on registration, but that's not hard.
Paul Hammant
added a comment - public FeatureUser ( Feature newfeature) {
}
... or ...
public FeatureUser ( @NewVersion Feature feature) {
}
.. in Pico 2.0.
Of course it requires your making a binding annotation or a doing USE_NAMES on registration, but that's not hard. Paul Hammant
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Fix Version/s | 2.0 [ 10411 ] | |
| Fix Version/s | 2.3 [ 14303 ] |
I missed the relationship in the previous example
class OldFeature implements Feature
class NewFeature extends OldFeature
class FeatureUser {
public FeatureUser ( Feature feature)
{ // can i get an instance of NewFeature }}