JSR 299 (Contexts and Dependency Injection for Java) support?
James Strachan
250 support I just wanted to mention JSR 299 (what used to be called
"Web Beans"
http://macstrac.blogspot.com/2009/03/jsr-299-contexts-and-dependency.html
initially I thought it was a bit pants - but on reading a recent draft
it looks very close to lots of Guice 2 annotations
(@Produces/@Provides, @Named, @BindingAnnotation/@BindingType etc).
It'd be awesome if one day we could have a Guice module that worked
with JSR 299's annotations.
I wonder have any guicer's read the spec & have any feedback? Sure
Guice can do loads of good stuff not in the spec; but what is in the
spec in the dependency injection & scopes part - does seem to map to
Guice spookily well and solves a pretty reasonable first stab at an
80% solution of the dependency injection space.
In attempting to implement it with Guice the main complication seems
to be using the extra development/production deployment annotation
matching stuff - which is quite handy - and that producer methods
don't have to be on a Module implementation (which is also useful).
Thoughts?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Ales Justin
James Strachan
>
> Afaik Bob did some initial work/ideas with Gavin on this.
It does look very Guicey :)
Ales Justin
- http://in.relation.to/Bloggers/FirstBetaOfWebBeansAvailable
Endre Stølsvik
>
> Afaik Bob did some initial work/ideas with Gavin on this.
Sep 21, 2007, Gavin King:
http://in.relation.to/Bloggers/WebBeansSneakPeekPartIIntroducingWebBeans
"The component model is deeply influenced by Google Guice and Seam."
(Review of above articles:
Sep 24, 2007: http://www.infoq.com/news/2007/09/webbeans-preview)
Feb 11, 2009: http://in.relation.to/10664.lace
"The revised Public Review Draft of Contexts and Dependency
Injection (JSR-299, the spec formerly known as Web Beans) was approved
by the EC with all EC members voting Yes"
Sounds like a standardization of Guice?! :)
Endre.
Bob Lee
So far, I haven't bothered to actively oppose 299 for a few reasons:
1) 299 doesn't seem to have gained any real traction. Only RedHat is pushing it. You've heard of design by committee? 299 is design by Gavin. :-)
2) 299 is part of EE, which we don't use or care much about. I think the risk of 299 imposing itself on SE is zero.
3) I choose to spend my time constructively (on the Java language, Guice, JSR 166, Android, etc.), not playing political games.
My advice to our users is to continue using the Guice API. Your code will be more maintainable as a result. JSR 299 does not represent consensus. It's a land grab by unqualified vendors who would rather prematurely set an unproven design in stone than compete on a level playing field. It's EJB and JSF all over again. By comparison, the Guice API has enjoyed many times the scrutiny by people who actually use and understand this stuff. Guice is simpler, better specified and more future proof as a result.
In other words, Guice will not directly support 299, but you could easily build a 299 extension for Guice. You'd be better off sticking to the Guice API though.
Bob
Ales Justin
Looks like you got serious beef with us (RHT):
- http://code.google.com/p/google-guice/issues/detail?id=288
(care to back up those claims?)
And Bob, thanks for replying to my Guice + MC feedback. ;-)
Bob Lee
Looks like you got serious beef with us (RHT):
I have no "beef" with anyone.
And Bob, thanks for replying to my Guice + MC feedback. ;-)
MC?
Bob
Ales Justin
> <mailto:ales....@gmail.com>> wrote:
>
> Looks like you got serious beef with us (RHT):
>
>
> I have no "beef" with anyone.
Sure you do.
Just re-read your post about RHT's impls,
either jsr-299 or concurrency stuff.
> And Bob, thanks for replying to my Guice + MC feedback. ;-)
>
>
> MC?
MC = JBoss Microcontainer
I posted some stuff on the Guice wiki,
eventually sending direct email to you,
asking about "state machine" handling in Guice
and how to best use best of both worlds,
but no reply/feedback.
I can see you're swarmed with other stuff since your blog really suffers,
so no "beef" from me about that.
It's just that I would handle that differently,
not playing like an "untouchable", specially after we got formally
introduced at JavaOne 2007. ;-)
Bob Lee
And Bob, thanks for replying to my Guice + MC feedback. ;-)
MC?
Oh, JBoss Microcontainer. I'm sorry I didn't respond to your email. I starred it in Gmail, but neglected to revisit due to time constraints.
Bob
limpb...@gmail.com
> In attempting to implement it with Guice the main complication seems
> to be using the extra development/production deployment annotation
> matching stuff - which is quite handy - and that producer methods
> don't have to be on a Module implementation (which is also useful).
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.
I'd be interested in seeing an unbiased comparison between Guice and
JSR 299 for real-world apps. If anyone is interested in putting a
document like that together, I volunteer to be a technical reviewer!
Brian Pontarelli
On Mar 17, 2009, at 6:37 PM, je...@swank.ca wrote:
>
> On Mar 17, 5:58 am, James Strachan <james.strac...@gmail.com> wrote:
>> In attempting to implement it with Guice the main complication seems
>> to be using the extra development/production deployment annotation
>> matching stuff - which is quite handy - and that producer methods
>> don't have to be on a Module implementation (which is also useful).
>
> 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.
JCatapult uses classpath scanning for Guice modules with support for
inheritance and it works pretty well. I haven't run into major issues
with it in general and it does simplify what we consider our general
usage cases. In general testing remains the same as any other
situation. Some tests inject the full service, some tests mock stuff
out, and some mock bits and pieces via additional modules or
inheritance. Both classpath scanning and testing can obviously break
down eventually, but I haven't hit that case yet.
Another general rule we put into JCatapult is always allow folks to
turn it off or tweak it. For this reason you can just flip a switch
and classpath scanning is turned off and it reverts to a configured
list of modules. We also added an excludes list when scanning is
turned on and a few other things.
I tend to like technologies that make things really simple up front
but also allow me to do whatever I want without major hassle.
-bp
Bob Lee
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
James Strachan
On Mar 19, 7:07 pm, Bob Lee <crazy...@crazybob.org> wrote:
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... :)
Bob Lee
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? :)
Definitely will do. In the mean time, your injectable type listener runs once when a type is first encountered, and it should do the up-front reflection work. It will find all methods annotated w/ @Resource, and then it will create a list of Pair<Method, Provider<Object>> objects that contain the method to be injected and the provider that provides the object to be injected. The injectable type listener registers an injection listener. The injection listener just iterates through the list of pairs, gets an object from the provider, and invokes the method passing in the provided object. In other words, the injection listener will be very fast and not even perform any lookups. In the injectable type listener, you use the Encounter to get the provider, register the injection listener, report errors, etc.
The same goes for supporting EJB interceptors.
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 agree that standard annotations would be useful. You'd also want to standardize the Provider interface. I'm not fond of 299's annotations though, and I think we should hold out for or even push for something better. We certainly shouldn't settle on the first solution to come along without considering its quality. 299 is only nominally a standard. The proposal's current scope has nothing to do w/ its original scope (integrating EJB and JSF). Why don't we all submit modest proposals and then go around standardizing whatever we feel like regardless of the scope, skipping that whole messy step where you have to actually work w/ other people and achieve consensus? The current spec represents Gavin's whims, not the community consensus you'd hope to standardize.
Specific issues off the top of my head:
- I don't like that you only need to use a binding annotation at an injection point. Binding annotations can have arbitrary names, so it makes it more difficult to tell which code is injected compared to always requiring @Inject.
- 299 at least has @Initialize for constructors, but I'm not even sure if I like that name. Yeah, a constructor initializes an instance, but I think we should be more explicit about the constructor being injected.
- I don't like that you can have sets of binding annotations. Using one binding annotation is rare enough to begin with. The cases where you'd want more than one binding annotation aren't compelling enough to justify the added complexity. I don't want to have to look for multiple binding annotations on an injection point and then have to find all the bindings that having matching binding type supersets. I prefer the simplicity of Guice's one-to-one, binding to injection point relationship.
- I don't like the name "produce". Provider methods don't always produce (create) something. Plus, it reminds me of the grocery store.
- How many annotation types does 299 have now? This is the kind of annotations-gone-wild result that the detractors had in mind when annotations first came out. You should use annotations tastefully and judiciously. You certainly wouldn't need most of those annotations if you use Guice.
- Arbitrary partial implementations of specs are bad for users, and I don't want my code to depend upon EJB.
Bob
James Strachan
But there seems to be zero movement on any other JSR to standardize
IoC annotations. I don't see Guice or Spring doing anything any time
soon. I'd rather have something, even sub optimal that we can use in
lieu of something better further down the road. The Java ecosystem is
littered with stuff that has been replaced (EJB1, Servlets (now JAX-RS
makes more sense), JAXB 1.0 etc.
If one day you & Rod can be bothered to hammer out a new JSR thats
better than 299 - great! But I don't see that happening any time soon
do you?
Hopefully we can feed your feedback to the JSR and try push for changes? :)
Dhanji R. Prasanna
James Strachan
> I don't think it's for lack of trying that there isn't a JSR.
> Also we worked pretty hard to keep JAX-RS free of inventing it's own DI and
> lifecycle which it was on the verge of doing (@Singleton, etc.). And am glad
> to say that for the most part sense prevailed.
> Most of this is just a fancy way of calling "new". Lately, Im beginning to
> wonder if we really need a standards committee to arbitrate its cosmetics...
> I'm sure that is not the popular view, however.
> Dhanji. =)
IMHO we badly need some standard annotations to be able to add to
objects which denote its injection points (optional + mandatory) with
optional qualifiers and scopes along with optional lifecycle
interfaces (which JSR 250 does a pretty good job of) - such that the
object can be then injected in any framework without having to write
custom providers/factory beans for each and every IoC framework.
Or to put that another way; having a stand set of annotations will
reduce the lock-in of Spring which seems to be used by pretty much all
customers I work with in Enterprisey places.
James Strachan
> On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <james.s...@gmail.com>
> wrote:
>>
>> 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? :)
>
> Definitely will do. In the mean time, your injectable type listener runs
> once when a type is first encountered, and it should do the up-front
> reflection work. It will find all methods annotated w/ @Resource, and then
> it will create a list of Pair<Method, Provider<Object>> objects that contain
> the method to be injected and the provider that provides the object to be
> injected. The injectable type listener registers an injection listener. The
> injection listener just iterates through the list of pairs, gets an object
> from the provider, and invokes the method passing in the provided object. In
> other words, the injection listener will be very fast and not even perform
> any lookups. In the injectable type listener, you use the Encounter to get
> the provider, register the injection listener, report errors, etc.
Great stuff - thanks for the heads up. That clears alot of confusion I had :)
Are you planning on adding a kinda higher level above the injectable
type listener so its easier to register providers for annotated
elements; or is whats there now the hooks you were thinking of and
everything else is up to the developer?
e.g. I'd like in a module to write code something vaguely like
bindAnnotationProvider(Resource.class, new
AnnotatedElementProvider<Resource.class>() {
Object provideValue(Resource annotation, AnnotatedElement element) {
...
}
});
giving the provider method access to the annotation & annotated
element (so things like the field/method name could be used) and
internally it would be doing the iteration over fields/methods to find
one with @Resource on it say.
I'm just wondering if its worth my time writing another patch that
never gets applied or should I just wait a while :)
limpb...@gmail.com
On Mar 31, 2:30 am, James Strachan <james.strac...@gmail.com> wrote:
> Are you planning on adding a kinda higher level above the injectable
> type listener so its easier to register providers for annotated
> elements; or is whats there now the hooks you were thinking of and
> everything else is up to the developer?
welcome a patch to our extensions/ tree that uses these new hooks for
J2EE integration. Would you be up for contributing that?
James Strachan
Sure! Though please give me a heads up if you're planning on doing it
yourselves to save me the effort :)
Bob Lee
Sure! Though please give me a heads up if you're planning on doing it
yourselves to save me the effort :)
We have no plans to implement EE support. As for the higher-level support for injection listeners, we have no plans here either. My hope is that we can build most things going forward as extensions and keep core Guice minimal (so I can run it on Android for example).
Bob
James Strachan
Cool. How about I try hack up a little prototype of JSR 250 in
guiceyfruit using the new injectable type listener - I'll point you at
the various little helper/facade objects I figure out and then if you
want them I can submit them as a patch to Guice otherwise we can leave
them as an extension module? To be honest its probably only gonna be a
few little helper classes; but then their use might not be that
widespread to be in the core of Guice - I'll let you decide when I've
figured something out. I'm easy either way really.
limpb...@gmail.com
On Mar 31, 1:20 pm, James Strachan <james.strac...@gmail.com> wrote:
> Cool. How about I try hack up a little prototype of JSR 250 in
> guiceyfruit using the new injectable type listener - I'll point you at
> the various little helper/facade objects I figure out and then if you
> want them I can submit them as a patch to Guice otherwise we can leave
> them as an extension module? To be honest its probably only gonna be a
> few little helper classes; but then their use might not be that
> widespread to be in the core of Guice - I'll let you decide when I've
> figured something out. I'm easy either way really.
fits in Guice's extensions/ or in Guiceyfruit. Thanks James.
James Strachan
OK I've got the @Resource injection and @PostConstruct working fine
now. (Work on @PreDestroy is currently pending - that might need a
patch or two on Guice yet - not sure).
There's not that much code used to implement this; so feel free to
lift whatever you like back into Guice.
Mostly the heavily lifting is done by 2 main helper methods on a base
AbstractModule...
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/support/GuiceyFruitModule.java
this provides basically 2 flavours of helper methods:
* bindAnnotationInjector(): binds an annotation with an
AnnotationMemberProvider (which is just like a Provider but its given
the annotation instance and member as parameters as well).
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/support/AnnotationMemberProvider.java
The first parameter is the annotation and the second is a key/type of
an annotationMemberProvider (so Guice can inject the instance). This
method is used to inject some arbitrary value into an annotated field
or method with a single parameter using a custom strategy to create
the value.
* bindMethodHandler(): binds an annotation with a MethodHandler which
allows an annotated method to be processed using a custom method
handling strategy.
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/support/MethodHandler.java
This could be a post commit style hook; but can also be for other
uses, like binding a method to some kind of event raising mechanism;
or in the case of Apache Camel to subscribe to some message bus or
other network protocol and bind the incoming messages to the method. A
POJO version of message driven beans if you will.
The second parameter in both methods can be specified as an instance,
a key or type. If its the latter 2 options then guice does the
injection. To simplify the code of the 3 versions of each method, I
created a little EncounterProvider helper class
http://code.google.com/p/guiceyfruit/source/browse/trunk/guiceyfruit-core/src/main/java/org/guiceyfruit/support/EncounterProvider.java
who's job it is to create a Provider of the strategy based on an
encounter and whatever the key is (Key or Class etc)
I'm not totally sold on the name "MethodHandler" its a bit vague :).
Its basically useful for either post construct callbacks or for event
binding type stuff.
All in all not very much code; so it could well move into the core of
Guice if you like.