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/
It does look very Guicey :)
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.
Looks like you got serious beef with us (RHT):
And Bob, thanks for replying to my Guice + MC feedback. ;-)
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. ;-)
And Bob, thanks for replying to my Guice + MC feedback. ;-)
MC?
>
> 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
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.
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? :)
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.
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? :)
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.
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 :)
Sure! Though please give me a heads up if you're planning on doing it
yourselves to save me the effort :)
Sure! Though please give me a heads up if you're planning on doing it
yourselves to save me the effort :)
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.
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.