On Mar 19, 7:07 pm, Bob Lee <[email protected]> wrote:
> 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."
Agreed - and thats great to hear, keep up the great work! Looking
forward to being able to use @Resouce for real in Guice!
As an aside - I tried noodling the recent changes and couldn't quite
get my head around them - any chance you could hack up a little test/
demo to show how the new stuff is meant to be used to implement a
custom injection point like @Resource? :)
BTW in this Guice v 299 discussion - I don't personally care too much
about the JSR 299's XML stuff; whether classpath scanning with
annotations is used or a Guice Module. I can see the value in all of
them - but I'm less bothered about those bits being standardised.
I'm more bothered about a standard set of annotations we can put in
our zillions of objects out there which are IoC container agnostic -
which could then be used by 100% pure Guice code (using Guice modules,
module inheritance, private modules at al), or a JSR 299 provider - or
Spring with some BeanPostProcessor handling the JSR 299 injection
annotations.
Then whether one team takes a set of beans and uses JSR 299's XML
stuff, uses classpath scanning, uses Guice with its Modules or uses
Spring's JavaConfig or XML config - I don't much care, its up to them.
What I really hope we can avoid is having code that is annotated - say
- with Spring specific annotations; making folks think you must stick
with Spring XML to dependency inject that code or face the prospect of
writing a ton of provider methods etc. (Or starting annotation wars
where different teams keep searching & replacing Guice annotations to
Spring and vice versa).
Standards are hard to achieve; but at the bean/service implementor
level the annotations in JSR 299 look pretty good to me (they mirror
nearly exactly the Guice ones :) - I don't mind so much if the rest of
the spec (the XML stuff & classpath scanning stuff) becomes an
optional feature that folks don't use with Guice - or if folks using
Spring reuse the classpath scanning in Spring etc.
With the new extension points in Guice it should be possible (I hope)
to implement support for JSR 299 annotations on beans/services - yet
reuse the nice stuff in Guice (modules etc). Or to say that another
way; if we can find a small, common base of interoperability in the
IoC/DI space then allow innovation at the edges & above the spec (e.g.
Guice Modules v XML v classpath scanning) we will drastically lower
the barrier to switching from one IoC container to another which
should help foster more innovation and prevent lock in from the
established XML heavy containers.
i.e. making it much easier for more enterprisey users to being able to
easily switch to Guice... :)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
