commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: Project Proposal?
Date Fri, 05 Aug 2005 11:39:45 GMT
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

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 [] 
Sent: Friday, August 05, 2005 2:37 AM
To: Jakarta Commons Developers List
Subject: Re: Project Proposal?

Out of interest, why and not sandbox? :)

Before that sounds like a witch-hunt, I'm as guilty in that I start
all my stuff at 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 and 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

One question I'd like to ask is whether we would accept mature components. 

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


On 8/4/05, James Carman <> wrote:
> Well, I went ahead and started the project over at, but we can
> 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, so you guys won't be able to see anything
> yet.  It should be approved soon though.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message