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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
