Patch for web ... to close that static getter IoC problem

[Paul Hammant-3]

Well it goes part way.
By extending a filter, we can use some private magic to hide the  
static thread local vars that would otherwise make things publicly  
available.

It dictates a scenario where there is only one pico-leveraging filter  
per web app. And only one 'ActionFactory' thing that is using that.  
Axis and Webwork1 have two things - so it needs more thought.

Axis - PicoMsgProvider, PicoRpcProvider
WebWork1 - PicoActionFactory, WebWorkVelocityServlet

Thoughts?

- Paul



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

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Paul,

Paul Hammant wrote:

>
>
> Well it goes part way.
> By extending a filter, we can use some private magic to hide the
> static thread local vars that would otherwise make things publicly
> available.
>
> It dictates a scenario where there is only one pico-leveraging filter
> per web app. And only one 'ActionFactory' thing that is using that.
> Axis and Webwork1 have two things - so it needs more thought.
>
> Axis - PicoMsgProvider, PicoRpcProvider
> WebWork1 - PicoActionFactory, WebWorkVelocityServlet
>
> Thoughts?

what I am always curious about is, whether there is a real need for the
different containers. Do we really have different component types for the
sessions or requests or is it that we need separate instances? In the
latter case, there's absolutely no need for thread local containers at all.
All you need are different component adapters. Like the ThreadLocalized you
simply need a RequestScoped or SessionScoped one and you will get a new
instance for each scope accordingly. The filter might add Picos to the
different scopes, but why do they have to be thread localized?

- Jörg



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

    http://xircles.codehaus.org/manage_email

[Konstantin Priblouda]

----[ Konstantin Pribluda http://www.pribluda.de ]----------------

> what I am always curious about is, whether there is a real
> need for the
> different containers. Do we really have different component
> types for the
> sessions or requests or is it that we need separate
> instances? In the
> latter case, there's absolutely no need for thread
> local containers at all.
> All you need are different component adapters. Like the
> ThreadLocalized you
> simply need a RequestScoped or SessionScoped one and you
> will get a new
> instance for each scope accordingly. The filter might add
> Picos to the
> different scopes, but why do they have to be thread
> localized?

Well,at least  there are hibernate sessions which require
certain lifecycle and  how do we provide it for them?  

Having 3 containers makes it easier, without proliferating
custom lifecycles through adapters.

regards


     

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

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

> what I am always curious about is, whether there is a real need for  
> the
> different containers. Do we really have different component types  
> for the
> sessions or requests or is it that we need separate instances?

It would be possible to have one container and use as(..) to push in  
components to the appropriate scoping level :

   container.as(APP_SCOPE).addComponent(Hibernate.class)
   container.as(SESSION_SCOPE).addComponent(ShoppingCart.class)
   container.as(REQUEST_SCOPE).addComponent(AddToCart.class)

Then as http requests happen, pre-process the whole container, setting  
the right cached session scoped things, and ensuring that none at the  
request level are cached.

For the remaining request, the ThreadLocal caching would make sure  
that the right cached instances were used for the http session and  
request.

> In the
> latter case, there's absolutely no need for thread local containers  
> at all.

You'd only dispense with ThreadLocal if you stored who containers as  
attributes in the session - the way we used to do it. now we just have  
the components wrapped

See 'StoreWrapper' in https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/src/java/org/picocontainer/behaviors/Storing.java

Meaning its a lot smaller to serialize than the whole container.

>
> All you need are different component adapters. Like the  
> ThreadLocalized you
> simply need a RequestScoped or SessionScoped one and you will get a  
> new
> instance for each scope accordingly. The filter might add Picos to the
> different scopes, but why do they have to be thread localized?

Kinda ..

   container.addComponent(Hibernate.class);
   container.addAdapter(new SessionScoped(new  
ConstructorInjection(ShoppingCart.class));
   container.addAdaptert(new RequestScoped(new  
ConstructorInjection(AddToCart.class));

.. I still think it needs thread local to make it work.

- Paul

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

    http://xircles.codehaus.org/manage_email

[Michael Rimov]

 

> > what I am always curious about is, whether there is a real need for
> > the
> > different containers. Do we really have different component types
> > for the
> > sessions or requests or is it that we need separate instances?
>
> It would be possible to have one container and use as(..) to push in
> components to the appropriate scoping level :
>
>    container.as(APP_SCOPE).addComponent(Hibernate.class)
>    container.as(SESSION_SCOPE).addComponent(ShoppingCart.class)
>    container.as(REQUEST_SCOPE).addComponent(AddToCart.class)

Correct.  In fact, I _thought_ that's what you were going to do with your last
refactoring of pico-web.  

> Then as http requests happen, pre-process the whole container, setting
> the right cached session scoped things, and ensuring that none at the
> request level are cached.

And that's exactly what the ABORT_TRAVERSAL feature of visitor was added for: So
you can process the app-level container for components without accidentally
pre-processing any child containers.  

Of course, you would still need the ThreadLocal so each request-level component
adapter instance would know where to store its stuff since ComponentAdapter
instances would be shared across requests.  (Which I think, is what you're
trying to say :) )

That said, you wouldn't need a ThreadLocal for the current application
container, like you do in PicoServletContainerFilter, would you?



                                                        -Mike


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

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

Correct.  In fact, I _thought_ that's what you were going to do with your last
refactoring of pico-web.  

We still could do that as well.

Then as http requests happen, pre-process the whole container, setting

the right cached session scoped things, and ensuring that none at the

request level are cached.

And that's exactly what the ABORT_TRAVERSAL feature of visitor was added for: So
you can process the app-level container for components without accidentally
pre-processing any child containers.  

Of course, you would still need the ThreadLocal so each request-level component
adapter instance would know where to store its stuff since ComponentAdapter
instances would be shared across requests.  (Which I think, is what you're
trying to say :) )

:)

That said, you wouldn't need a ThreadLocal for the current application
container, like you do in PicoServletContainerFilter, would you?

We're not setting the app container to be thread-local managed, it's classic new Caching() right ?

- Paul