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

Michael Rimov wrote:
> 
> 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.

I had not noticed that :-)  I'll take a look ...

>> 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/

the persistence-hibernate is meant for people that choose not to use 
annotations.  It already has been upgraded to latest 3.2.x release.
IMO, this should be kept as it allows folks choice on use of annotations.

> 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).

We can keep it if there is a consensus, but IMO it's been made redundant 
by other DI-enabled web action frameworks, eg Waffle, but not only.

>> 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.)
> 

My thoughts entirely :-)  Yes - the releases would be staged and 
incremental.  I'll wait to see if there are objections from others 
before putting down a migration/release plan with detailed names etc ...

Cheers


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

    http://xircles.codehaus.org/manage_email