On Tue, Mar 17, 2009 at 5:37 PM, [email protected] <[email protected]>wrote:
> The last time I looked, JSR 299 doesn't have the concept of a Module. > Instead, the configuration uses classpath scanning, annotations and > annotation-like XML. I anticipate that this may make testing > cumbersome, but I haven't tried it. The "deployment type" is 299's less flexible alternative to a module. In 299, you can annotate a "bean" with a deployment type annotation. In Guice speak, this would be like an implementation class saying, "I'm part of module 'foo'." You could easily implement "deployment type" support with a custom Guice module (that scans the classpath and creates bindings), but implementing modules on top of deployment types is not possible. All configuration in 299 is inherently global. I'm not sure how 299 will ever support non-trivial applications where you need to vary your configuration within different components. 299 tries to solve everyone's problems natively. For example, they plan to make their annotation model flexible enough to superset other models like JAX-RS (http://in.relation.to/10507.lace). While it may work OK with existing use cases, I doubt it will age well. Guice, on the other hand, attacks the problem twofold: 1) Provide a simple, easy to use, tasteful, annotation-based injection model for applications. 299 complicates binding resolution by annotating impl classes, matching sub types, introducing binding annotation sets and stereotypes, and adding deployment type precedence, all things that might sound cool to inexperienced people trying to imagine what a DI framework should look like. These features add little (no?) value, and they make your configuration much harder to understand without tools. Our experience tells us that users actually need compartmentalized configuration, so we've introduced private modules and child injectors in Guice 2. 2) Only one framework can create an object. If we're going to be that framework, we need to provide an extensible platform to support other solutions like @Resource. We're continuing the work started by James Strachan and finishing up a small set of flexible hooks (Module, InjectionListener, Provider, etc.) that enable just about anything you could want to do. I think this approach will prove to be much more future-proof than building out "by far the most sophisticated annotation and XML based metadata reuse and overriding scheme ever devised." Bob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
