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]
