Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.0-beta-5
-
Fix Version/s: None
-
Component/s: PicoContainer (Java)
-
Labels:None
-
Number of attachments :
Description
Hello,
current implementation of DefaultPicoContainer uses a private lifecycle adapter initialized automatically. This makes it hard to create an extended LifecycleAdapter and derive from DefaultPicoContainer that will use it. Changing:
======= snip =======
private final LifecycleAdapter lifecycleAdapter = new LifecycleAdapter(this);
======= snap =======
to
======= snip =======
protected final LifecycleAdapter lifecycleAdapter = createLifecycleAdapter()
protected LifecycleAdapter createLifecycleAdapter()
======= snap =======
would support this scenario.
Reasoning: I would like to support a verification step before starting a component for components based on a JavaBean or support JMX. Verification makes only sense after all configuration parameters of the instance have been set. See also Leo Sutic's analysis of the situation: http://www.mail-archive.com/dev@avalon.apache.org/msg13106.html
Regards,
Jörg
Activity
Aslak Hellesøy
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Closed [ 6 ] |
| Assignee | Aslak Hellesoy [ rinkrank ] | |
| Resolution | Won't Fix [ 2 ] |
This is obsolete as of yesterday.
We decided to move all the multicaster magic out of DefaultPicoContainer and into picoextras-multicast.
(The reason being that we want to reduce PicoContainer to a strict minimum of features - as this will make maintenance of the core API a lot simpler for the future).
The current implementation of start() stop() and dispose() use simple casting. No proxies involved.
Advanced, pluggable lifecycle management is still possible using picoextras-multicast. (It will probably be refactor into something a tad simpler in the near future - it is too complicated now).
I believe that in this API you should have enough flexibility to do what you want.
If not, please reopen this issue.