commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject RE: Project Proposal?
Date Fri, 05 Aug 2005 15:35:55 GMT
The Syringe API lends itself to setting things up with code.  The HiveMind
API wasn't really meant for that.  It was written with the hivemodule.xml
file syntax in mind and with everybody chanting "less XML is good", we've
had some folks requesting a more API-based approach.  So, you're right,
Siringe is indeed a framework, but it's a lower-level framework.  Something
like HiveMind would sit on top of syringe (as painful as that may sound).  I
would like, someday, to port HiveMind to use the Syringe API underneath, but
that would be quite an undertaking and there are quite a few folks out there
already using HiveMind (anyone using the newest Tapestry, for example).  I
wanted to start something fresh with no limitations of backward
compatibility and see what I came up with.  Hopefully folks with think that
Syringe is easy to use/extend.  I'm working on an example application right
now to see how really easy it is (eat my own dog food).  Hopefully the
example will serve as documentation and an opportunity to figure out how to
make Syringe that much more usable.

Since it is a framework, would I have to submit a "Jakarta PMC TLP
Application" if I wanted to eventually move this project to Apache?  Is
there no real "incubator" inside Jakarta for projects such as this?  Sounds
like I may have chosen the right place for this project for now.


-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Friday, August 05, 2005 8:39 AM
To: Jakarta Commons Developers List
Subject: RE: Project Proposal?

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



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