Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.0-beta-5
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
hi,
I've just been porting my application to the latest pico and stumbled accross a very annoying issue and there is no easy way to fix it other then rewriting most parts of the container.
Source of all evil is "getComponentInstanceOfType(Class type)" and that it navigates the whole tree to look for a statisfiable type. Unfortunatly this always results in multiple Adapters if you use the Decorator [GoF] pattern in your code.
I will attach a testcase and would like to get some comments as this is closely linked to
http://jira.codehaus.org/secure/ViewIssue.jspa?key=PICO-105
and I will need to start "fixing" this tommorrow and if the general consent is that Keys I would do part of that refactoring too, but could use some support there.
Issue Links
- depends upon
-
PICO-105
Remove key from ComponentAdapter
-
Activity
Thomas Heller
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | patch.zip [ 11328 ] |
should of course say "... consent is that Keys better be moved away from the Adapters I would do part of that refactoring too ..."
Thomas Heller
added a comment - should of course say "... consent is that Keys better be moved away from the Adapters I would do part of that refactoring too ..." Here's a very naive fix. All testcases pass and the "problem" is solved. I say naive cause Keys really should be handled more properly but thats another point of discussion.
Thomas Heller
added a comment - Here's a very naive fix. All testcases pass and the "problem" is solved. I say naive cause Keys really should be handled more properly but thats another point of discussion. Thomas Heller
made changes -
| Attachment | patch.txt [ 11329 ] |
Aslak Hellesøy
made changes -
Good contribution. Applied with some minor modifications:
- There is no need to look in the parent, as PicoContainer.getComponentAdapter(Object key) walks up the hierarchy. (And btw, you were only looking up one parent anyway
)
- Simplified the test a bit, and changed the test name to make the intent clearer.
Aslak Hellesøy
added a comment - Good contribution. Applied with some minor modifications:
There is no need to look in the parent, as PicoContainer.getComponentAdapter(Object key) walks up the hierarchy. (And btw, you were only looking up one parent anyway )
Simplified the test a bit, and changed the test name to make the intent clearer.
Aslak Hellesøy
made changes -
| Fix Version/s | 1.0-beta-5 [ 10145 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
run
o.p.d.ComponentKeysTestCase.testComponentKeysTakePrecedenceOverImplementation()