Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 2.0
-
Fix Version/s: 2.2
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
Hey Folks,
as you might know I've been on a custom PicoContainer for quite some time and learned quite a few things in my time there. This is the first step I'd like to take in direction of Pico2.0.
Explanation follows on mailing list.
Activity
Thomas Heller
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Attachment | pico.tar.gz [ 13229 ] |
Added Lifecycle changes, see mailing list for explanation.
Thomas Heller
added a comment - Added Lifecycle changes, see mailing list for explanation. Thomas Heller
made changes -
| Attachment | pico2.tar.gz [ 13230 ] |
Jörg Schaible
made changes -
| Component/s | PicoContainer (Java) [ 10191 ] | |
| Priority | Critical [ 2 ] | Major [ 3 ] |
| Environment |
Pointer to original thread: http://thread.gmane.org/gmane.comp.java.picocontainer.devel/3889
Jörg Schaible
added a comment - Pointer to original thread: http://thread.gmane.org/gmane.comp.java.picocontainer.devel/3889 Ok, I like this much better. The only thing is that we need a way to be able to actually get the to the Features for customization, modification.
Aside from the fact that there's a Java 5 generic reference in the default component adapter, I don't see anything that would prevent this from being able to be merged into the Pico code base today.
Instead of calling it DefaultComponentAdapter, we could call it FeatureComponentAdapter or something like that. (You guys are always better with the names!) Create a component adapter factory for this with the appropriate modifications.
Then by bringing feature implementations along-side it, we could have a migration path. HotSwapFeature, JMXFeature ....
I'm sorry if there's some ignorance going on here I tried pulling up the original thread link but got timeouts trying to connect but am I missing something?
-Mike (R)
Michael Rimov
added a comment - Ok, I like this much better. The only thing is that we need a way to be able to actually get the to the Features for customization, modification.
Aside from the fact that there's a Java 5 generic reference in the default component adapter, I don't see anything that would prevent this from being able to be merged into the Pico code base today.
Instead of calling it DefaultComponentAdapter, we could call it FeatureComponentAdapter or something like that. (You guys are always better with the names!) Create a component adapter factory for this with the appropriate modifications.
Then by bringing feature implementations along-side it, we could have a migration path. HotSwapFeature, JMXFeature ....
I'm sorry if there's some ignorance going on here I tried pulling up the original thread link but got timeouts trying to connect but am I missing something?
-Mike (R) Michael Rimov
made changes -
| Fix Version/s | 2.2 [ 14251 ] | |
| Fix Version/s | 2.0 [ 10411 ] |
I'm closing this issue because I believe Paul addressed it in version 2.0 ComponentAdapter and ComponentAdapterFactory implementations.
Reopen if I'm wrong 
Michael Rimov
added a comment - I'm closing this issue because I believe Paul addressed it in version 2.0 ComponentAdapter and ComponentAdapterFactory implementations.
Reopen if I'm wrong Michael Rimov
made changes -
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
We've done a lot in the same direction as Thomas outlined. Especially the naming changes.
addFeature(..) we did not do
Pico3 perhaps.
- Paul
Paul Hammant
added a comment - We've done a lot in the same direction as Thomas outlined. Especially the naming changes.
addFeature(..) we did not do
Pico3 perhaps.
Paul
Sample Implementation for CDI and Singleton caching only.