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

> At themoment I'm quite silent, but I follow
> the discussion closely.
> 
> Thread local is really dangerous - webservers
> do reuse threads. I got bitten in my ass more than
> once.

Konstantin,

Don't webservers only reuse a thread once one servlet request is complete??  

Currently, if I read the code right, the storage is only taking place during the
servlet request and gets destroyed as it comes back through the filter.


> BTW, do we need nanowar at all?  It's kind of spring
> way to try to provide everything and kitchen sink.
> 3-Tier container hierarchy is a good thing, and
> WW/S2 can profit from it.
> 
> But nanowar itself offers really poor functionality
> compared to XW / WW / S2 - or doyou like to
> reimplement parameter handling / conversion /
> propagation,
> validation, i18n, templating etc.?

Personally, I think that NanoWAR has something worthwhile to offer and in fact,
should be the jumping off point to provide integration with other frameworks.
For example, I think that  Pico -> FrameworkX integration should really be
(under the hood), NanoWAR -> FrameworkX integration.

In essence it provides a way to bind PicoContainer to a servlet environment.
Now NanoWEB on the other hand I think serves more as simple example to show how
integration could be done.  I never used it, but I did study it to figure out
how everything fit together.


Paul,  I've really been giving a lot of thought to the whole component
instance/lifecycle issue, and I guess I believe that the simplification gained
by having the restriction of Instance Registrations being only valid for the
Webapp-level services outweighs the negatives.  

As far as I can see, it finally unifies the application/session/request
containers into a single configuration script without ugly if/else blocks, and
that alone (IMO) solves the A-number-one ugly facet of NanoWAR 1.

							-Mike



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

    http://xircles.codehaus.org/manage_email