RE: [picocontainer-dev] Moving towards a Nano 2.x release

> now that Pico 2.2 is out, I feel we should take off the foot from the
> Pico pedal for a second and focus on Nano 2.x.

Yes, it would be good to have a NanoContainer 2 release.  Paul has done a
wonderful job on simplifying the Nano2 interface, IMO.  

> I've verified that all Nano unit tests pass with latest Pico release.
> But perhaps moving from 1.x to 2.x is a good opportunity to drop some
> old baggage - given that it's now 5 years since some of the modules were
> written or conceived.

Hi Mauro,

All the container-jython tests are failing under maven and disabled.  (See
NANO-193).  I've never been able to figure it out, so if somebody else could put
some eyes on it, it would be wonderful.

> Eg, I've dropped hibernate2 support from persistence, since Pico and
> Nano 2.x mandate JDK 1.5, I can't think of any reason why someone would
> still be on hibernate2 - if they do want to use of course, the 1.x
> versions still support it.

+10! :)  Perhaps we can drop Hibernate 3.0 as well?  (Not Hibernate 3.2 +
Annotations, just hibernate 3).  As of this August, it will be a 3 year old
release according to file timestamp:

http://mirrors.ibiblio.org/pub/mirrors/maven2/hibernate/hibernate/3.0/


> 
> A similar argument applies to some other libraries.  Eg:
> 
> - do we want to continue support for struts1 and webwork* now that t
> they've merged into struts2?

I'm for trimming the codebase, although I think recently there was somebody
looking to integrate webwork on the mailing lists (< 6 months ago IIRC?)  

> - does it makes sense to support nanoweb which was at best a proof of
> concept?  there are a number of web frameworks out there which support
> dependency injection.

True, but NanoWeb could live on as an example on how to use NanoWAR.  (I
remember going over it to figure things out, but I never used it personally.)  

I would actually like to see a little lighter weight version of a NanoWeb
component living on within NanoWAR.  Specifically have a Servlet and a Filter
that delegate all requests to a Servlet (or Filter) that has been instantiated
via DI.

Web.xml would look a bit like this:

<servlet>
	<name>LoginServlet</name>
	<class>org.nanocontainer.nanowar.DiServlet</class>
	<init-param>
		<param-name>delegate</param-name>
	
<param-value>org.nanocontainer.nanowar.sample.SampleLoginServlet</param-value>
	</init-param>
</servlet> 

The DiServlet would be a bit like this (psudocode):

public class DiServlet extends HttpServlet {
	private Servlet delegate;

	public void init(ServletConfig sc) {
				//Contents an exercise to the developer :)
		delegate = instantiateDelegateFromContainer(sc);
		delegate.init(sc);
	}

	public final void service(ServletRequest request, ServletResponse
response) {
		delegate.service(request,response);
	}

	public void destroy() {
		delegate.destroy();
	}	
}

A solution like this would be EXTREMELY light weight and allow a solution for
all those people out there that want DI, but don't want to mess with external
frameworks like Struts, etc. (Not to mention that after initialization, it would
be pretty much the fastest framework out there... only one function call slower
than a pure servlet and I bet with using final on service() that the JVM would
eventually inline it through optimization if needed).
 
> A more general note regards the use of the namespace nanocontainer.
> Would it make sense to drop it in favour of pico extensions, eg:
> - nanocontainer -> picocontainer-script
> - nanowar -> picocontainer-web
> - nanopersistence -> picocontainer-persistence

Well, I'm personally all for folding the Pico/Nano into a single namespace.  I
think PicoContainer is a developed brand name, Nano isn't. (IMO) :)  
 
Closing thought: Perhaps it would be best if we do fold Nano 2 into Pico that we
should only release one module at a time?  Ie:  First release
picocontainer-script.  Then as we flush out pico-web or pico-persistence, they
could be added to the release lists.

It seems that it might easier to manage and a little more along the spirit of
how Pico 2.X has been handled: one little refactor at a time. (And it would
allow us to more clearly see which modules are appropriate to drop.)

							-Mike



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

    http://xircles.codehaus.org/manage_email