Re: [picocontainer-dev] While looking at the streamlining of NanoWar ...

Something like :-

public class ChildlessSessionlessPicoContainer extends  
DefaultPicoContainer {

     // constructors

     public void start() {
         startAdapters();
     }

     public void stop() {
         stopAdapters();
     }

     public void dispose() {
         disposeAdapters();
     }

     public MutablePicoContainer makeChildContainer() {
         throw new UnsupportedOperationException();
     }

     public MutablePicoContainer addChildContainer(PicoContainer  
child) {
         throw new UnsupportedOperationException();
     }
}

Or does it beg for LifecycleState to be pluggable somehow and  
controlled per session/request via ThreadLocal and  
session.getAttribute(), request.getAttribute() ?

- Paul

On May 25, 2008, at 6:46 PM, Paul Hammant wrote:

> ... and given my task is to replace 'one container per session and  
> one container per request' with three 'static' containers + some  
> threadlocal store magic ...
>
> ... a problem is that start()/stop()/dispose() will have to be  
> rethought for session and request scoped components.
>
> Do people use lifecycle for session or request scoped components?
>
> - I'm guessing the answer is yes, but what for ?
>
> What if these session and request containers, did not have state  
> themselves, but merely cascaded start/stop/dispose to the components  
> they manage ?  i.e. StatelessPicoContainer (or better name)
>
>
> - Paul
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email