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).
> 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.
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"
If 299 looks superficially like Guice, it's because I was heavily involved. I left the EG over a year ago because I disagreed with the leadership and technical direction.
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 Lee wrote:
> If 299 looks superficially like Guice, it's because I was heavily > involved. I left the EG over a year ago because I disagreed with the > leadership and technical direction.
> 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.
> On Tue, Mar 17, 2009 at 4:17 PM, Ales Justin <ales.jus...@gmail.com > <mailto:ales.jus...@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. ;-)
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.
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!
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.
On Tue, Mar 17, 2009 at 5:37 PM, je...@swank.ca <limpbiz...@gmail.com>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."
> On Tue, Mar 17, 2009 at 5:37 PM, je...@swank.ca <limpbiz...@gmail.com>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... :)
On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <james.strac...@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.
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.
> On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <james.strac...@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.
> 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.
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? :)
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. =)
On Mon, Mar 30, 2009 at 9:08 PM, James Strachan <james.strac...@gmail.com>wrote:
> 2009/3/27 Bob Lee <crazy...@crazybob.org>:
> > On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <
> james.strac...@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.
> > 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.
> 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? :)
> 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.
> On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <james.strac...@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
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 :)
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?
Yeah, everything else is up to the developer. But we would certainly
welcome a patch to our extensions/ tree that uses these new hooks for
J2EE integration. Would you be up for contributing that?
> 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?
> Yeah, everything else is up to the developer. But we would certainly > welcome a patch to our extensions/ tree that uses these new hooks for > J2EE integration. Would you be up for contributing that?
Sure! Though please give me a heads up if you're planning on doing it yourselves to save me the effort :)
On Tue, Mar 31, 2009 at 12:47 PM, James Strachan <james.strac...@gmail.com>wrote:
> 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).
> On Tue, Mar 31, 2009 at 12:47 PM, James Strachan <james.strac...@gmail.com> > wrote:
>> 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).
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.
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.
Excellent. When it's all done we'll take a look and decide if best
fits in Guice's extensions/ or in Guiceyfruit. Thanks James.
> 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.
> Excellent. When it's all done we'll take a look and decide if best > fits in Guice's extensions/ or in Guiceyfruit. Thanks James.
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.
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.
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-... 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.
|
