On 27/04/10 09:00, [email protected] wrote: > On Apr 26, 11:56 pm, Max Bowsher <[email protected]> wrote: >> I think the reason it keeps coming up is that Guice core knows how to do >> an injection (java.util.logging.Logger) which a Guice user absolutely >> cannot configure a similar injection themselves. I certainly don't like >> this fact. > > Personally I'd rather remove Guice's ability to inject loggers than to > expand it for more pluggability!
That would be one way of resolving the situation. > Is there a specific case that custom injections doesn't cover? I'd > prefer not to overload the @Inject annotation for arbitrary non- > binding behavior, since that makes it more difficult to predict what > an injection will do. I don't consider an InjectionPoint-aware Provider to be "non-binding behavior" - it's still a case of "lookup Key, call associated Provider, inject returned result" - just that the Provider now has the ability to vary the details of the provided object based on the InjectionPoint context. > http://code.google.com/p/google-guice/wiki/CustomInjections Custom Injections are a wonderful tool for implementing addons for implementing @PostConstruct, for example. However, they feel quite cumbersome when all you want to do is *inject* one field/method with an esoteric object, and you have to write the reflection code yourself to do what Guice already has the infrastructure to do, if it's possible to express your object creation as a Provider.
signature.asc
Description: OpenPGP digital signature
