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

> 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'm all for deleting the Jython bindings. Its not easy to work with at  
all.

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

Agree.

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

Well both the WebWork and the Struts team would suggest that their  
best practice would be to move to Struts2.

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

Well work towards that if you like dude.

I'm thinking that Waffle is the direction I'd like to head in as the  
approved web-framework for Pico.

and maybe we could beef up the web-frameworks.html page with a "roll  
your own" section ?


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

Agree.

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

yup, but with same release numbers.

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

ack.

- Paul

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

    http://xircles.codehaus.org/manage_email