commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject RE: Project Proposal?
Date Fri, 05 Aug 2005 12:38:47 GMT
While interesting, this would have caused issues in
commons. The commons charter explicitly avoids
frameworks, and this is definitely a framework.

Longer term though, with Spring, Hivemind and Pico
already in this space, and EJB3 making some moves
there must be a limit on having a new injection
framework. So, why not just improve Hivemind?

Stephen

--- James Carman <james@carmanconsulting.com> wrote:
> I guess I wanted a little more freedom/control over
> the project at this
> phase.  Also, I wasn't too sure about licensing
> issues with putting stuff in
> the codebase that depends upon code outside Apache
> (the build file
> automatically downloads its dependencies from
> Ibiblio).  
> 
> It is early on right now, but I think there are some
> sound ideas there...
> 
> 1.  Proxy Factories - All proxies in Syringe are
> created using a proxy
> factory (an interface).  Using syringe, you never
> have to write the proxying
> logic code yourself anymore.  Furthermore, since
> it's abstracted out, it's
> easy to switch between (or mix and match for that
> matter) proxying
> strategies, simply by supplying a different
> implementation class.  I
> currently have implementations using JDK proxies and
> CGLIB.
> 
> 2.  Object Providers - Objects are provided to
> Syringe through
> ObjectProviders.  There are two different types of
> ObjectProviders now, core
> object providers and wrapper/decorator providers. 
> The core providers would
> be responsible for constructing/finding the actual
> implementation object.
> It might be a simple JavaBean, or it could be some
> sort of remote object
> (EJB, JAX-RPC, RMI, Burlap, etc.).  The
> wrapper/decorator providers
> supplement these core providers with additional
> functionality.  For example,
> in Syringe, all dependency injection is done using a
> decorator provider.
> So, it's easy for you to extend Syringe with your
> own providers and still
> support DI.  This has been somewhat of a problem in
> HiveMind.  All of the
> dependency injection logic is buried inside the
> BuilderFactory's
> implementation.  
> 
> 3.  Method Interceptors - Syringe only supports the
> MethodInterceptor
> interface (a proxy factory must know how to create a
> proxy which goes
> through a MethodInterceptor) from the AOP Alliance
> API.  Since this is
> somewhat of a "standard" API, I don't really see it
> as a limitation.  If we
> see the need to support other mechanisms, maybe we
> can provide adapter
> classes to bridge the gap.
> 
> 
> 
> -----Original Message-----
> From: Henri Yandell [mailto:flamefew@gmail.com] 
> Sent: Friday, August 05, 2005 2:37 AM
> To: Jakarta Commons Developers List
> Subject: Re: Project Proposal?
> 
> Out of interest, why java.net and not sandbox? :)
> 
> Before that sounds like a witch-hunt, I'm as guilty
> in that I start
> all my stuff at osjava.org and I can definitely list
> some reasons why.
> 
> Some may be bad:
> * Embaressment for dumb ideas :)
> * Don't want to be weighed down by a weighty release
> system.
> * Big painful website.
> * Might compete with another Commons component.
> 
> Some may be good:
> * Does the ASF want single-person codebases when an
> idea doesn't pan out.
> * If it fails, I'd then be forking it elsewhere
> which feels worse than
> just starting elsewhere.
> 
> What if we had a location within which ASF
> committers can bring their
> half-cocked component ideas? Try to encourage
> migration to the ASF and
> its benefits:
> 
> * bandwidth, though sf.net and java.net can solve
> that too. So can
> building your own system to the level of Codehaus.
> * legal protection.
> * better user acceptance.
> * community.
> 
> If we couple this with:
> 
> * much better management of the sandbox, and
> components that have failed.
> * a plan for mature components.
> 
> could we pick things up in terms of vibrancy? My
> biggest worry would
> be whether the mailing list becomes a bottleneck.
> 
> Half-baked idea (it's late): Each component has its
> own mail alias
> which gets forwarded to particular lists. These
> lists could represent
> the state of maturity of a component. Probably crap,
> just throwing it
> out.
> 
> One question I'd like to ask is whether we would
> accept mature components. 
> 
> Take http://www.osjava.org/norbert/, HttpClient said
> they were
> interested in using it and the thought was to put it
> in Commons. My
> only concern is that I can't see a lot more to do
> with it code-wise,
> so I'm hesitant to dump it in Commons, and yet I
> think it's a good
> tiny component that could do with being more open.
> 
> Hen
> 
> On 8/4/05, James Carman <james@carmanconsulting.com>
> wrote:
> > Well, I went ahead and started the project over at
> java.net, but we can
> move
> > it later if need be.  It's a dependency injection
> framework called
> > "syringe."  The project uses the Apache License,
> Version 2.0.  It's still
> > "pending approval" at java.net, so you guys won't
> be able to see anything
> > yet.  It should be approved soon though.
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message