Thanks, everyone, for the encouragement. Guice is still very much in the early stages, and I'm trying not to draw too much attention/scrutiny at this point. Guice is usable though. In fact, we've been running it in production for a couple release cycles now.
Check out the issue tracker to see what's in the works: http://code.google.com/p/google-guice/issues/list I set up a mailing list: http://groups.google.com/group/google-guice I'm putting a big focus on limiting magic, enabling static checking, keeping things simple, and performance. To address Konstantin's points: On 11/15/06, Konstantin Priblouda <[EMAIL PROTECTED]> wrote:
I do not like idea of "scope" - it's kind looks "springy" to me. Scope can be obtained easily by using container hierarchy ( like nanocontainer does - it registers 3 container hierarchy with managed lifecycles, or possibly more like "one container per directory / package " )
I'm aware of the container per scope pattern. The first time I saw it was when Joe Walnes did it with WebWork's DI container (before Spring and Pico existed). I actually tried the container per scope approach with Guice first. It worked fine for hierarchical scopes, but not so well for others, i.e. thread local, transaction, etc. I do need to use an interface instead of an enum for scopes I've decided. Storage of wiring information in annotations is a nice
idea, but not really flexible ( Is it posssible to manipulate annotations on a class, or are they bound at compile time? )
I may add support for this somehow, but maintenance is a big concern here. Right now, the primary goal is to help users design their own code well and avoid boilerplate and repetition and static dependencies. So, there is definitely no need to invent yet another
DI container for xwork unless you have fun of it ;)
I respectfully disagree. :) Thanks, Bob
