For what it's worth, I've done something vaguely like what you're after with a ProvisionListener:
https://github.com/timboudreau/giulius/blob/master/giulius/src/main/java/com/mastfrog/giulius/Dependencies.java#L578 I.e. use ProvisionInvocation.getBinding().getKey() to find out what type is being injected into, set that in a ThreadLocal and have the Provider check the value and do something based on it. That being said, I regret writing this feature - it was a lot of complexity for comparatively minimal utility. If there is enough information to infer what kind of Alert is needed by introspecting the type you're injecting the Alert into (say, looking at some annotations on that), then that approach might do the job. Or if some code up the stack has enough information to decide what Alert to create, you could use a custom scope, bind the Alert in there and put it in for later code to retrieve and use. That said, I'd question the utility of having lots of empty Alert subinterfaces that exist just be the bearer of a runtime annotation. If you're stuck with it, it is what it is, but there are simpler and more intuitive ways to solve that problem with far less boilerplate. -Tim On Monday, May 4, 2015 at 9:05:08 AM UTC-4, David Nouls wrote: > > In my applications I need to be able to have some influence on how Guice > searches for bindings. > > The problem that I am trying to solve: > I have a system to generate alerts. The code that generates these alerts > need to declare an interface that extends a marker interface and all the > methods use annotations to declare the actual text with placeholders for > the parameters. The actual implementation of this interface is done by one > single dynamic proxy implementation. For example > > public interface Alerts {} > > public interface TestAlerts extends Alerts { > @Alert( "Hello {0}" ) > public void hello( String text ); > } > > In the application code I inject the TestAlerts and use it like a regular > object. The advantage of this approach is that I get nice compiler warnings > whenever a change to parameters is done, or a message has been removed from > the Alerts interface. I can also do decent formatting and type conversion > without complicating the code that uses my Alert system. > > > Right now I have 2 possibilities in Guice: > 1) bind all interfaces that extends Alerts with a provider that can create > the dynamic proxy specific to the requested interface. > 2) Inject an AlertFactory that has a <V extends Alerts> V create(Class<V> > typeClass ) method. > > Solution 1 becomes tedious because in my case we are talking about > hundreds of injections (large enterprise system with lots of independent > components). > Solution 2 exposes the fact that you need to use a factory to send a > simple alert. Somehow this feels a bit like an anti-pattern because I am > not interested in how to create these objects, I just want on instance by > magic as I am used in injection frameworks. > > I've read and tried the documentation section on custom Custom Injections > <https://github.com/google/guice/wiki/CustomInjections>. But is very > incomplete, since it only allows injection into members, not constructors > and it requires you to use a custom annotation, not @Inject which basically > already requires the class to know that what he is depending on needs some > kind of extension - which sounds like an anti-pattern to me. > > I would like to be able to somehow register that Guice should use a > Factory that takes an argument of type class<V extends Alerts>. Or someway > to register a TypeListener that gets invoked when some unknown type is > requested for injection. > > Any ideas how to do this ? Any chance of getting some extra extension > point in Guice to go a step further with extensions ? > > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/436652f8-68e6-4bec-9a05-424d0706d7c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
