On Fri, Mar 27, 2009 at 6:32 AM, James Strachan <[email protected]>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. 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 -~----------~----~----~----~------~----~------~--~---
