Bug 368240

Comment 1 Greg Wilkins 2012-01-10 08:17:37 EST

The terminology I've used is the concept of "joined", ie if you want
to stop with a thread, you join with it.  In  this context if a bean
is joined, then it's lifecycle is linked.  If it is disjoint, then
it's lifecycle is not linked. So the normal addBean(Object) method
remains, and it assumed any lifecycle bean that is already started is
not joined. If you want to explicitly control joined status, you can
use methods

 addBean(Object, boolean)
 join(Object)
 disjoin(Object)
 isJoint(Object)

These are all thread safe, so can be done at anytime.

So if you want to share a thread pool, you can do something like:

 ThreadPool t = new ThreadPool();
 t.start();

 AggregateLifeCycle a0 = new AggregateLifeCycle();
 a0.addBean(t);
 a0.start();

 AggregateLifeCycle a1 = new AggregateLifeCycle();
 a1.addBean(t);
 a1.start();

 a0.stop();
 assert t.isStarted();

 a1.stop();
 assert t.isStarted();

 t.start();


Now the catch is, that HttpClient and the Connectors are currently not
AggregateLifeCycles... because they extend HttpBuffers instead!   Doh!
Well I think the IS-A relationship holds better to the
AggregateLifeCycle than it does to HttpBuffers... so I think we can
work around this by:

 + make HttpBuffers an interface
 + HttpClient and AbstraceConnectors will implement HttpBuffers
 + create a HttpBuffersImpl class
 + HttpClient and AbstraceConnectors will contain a HttpBuffersImpl
and delegate methods to it
 + HttpClient and AbstraceConnectors will extend AggregateLifeCycle
and the threadpool will be added as a dependent bean (join or not
depending).

Comment 2 Greg Wilkins 2012-01-10 19:11:43 EST

changed names from join/disjoin to manage/unmanage