Thanks for the link, I did not find that one before. >From what I read in the bug report they need a compelling use case. Assuming that there is no need for this because after 4 years of discussions nobody joined the discussions is an easy answer. Most people just don't bother joining in the discussion for various reasons.
For me my example is a compelling case. Requiring duplication of bindings (in my case 100+) is very tedious. Injecting a Factory instead is also no so nice (but workable at this moment). And my case does not ask for a complete freedom, I need to register with some base class or matcher that would allow me to construct the required binding. How did the Custom Injections get accepted in Guice ? It is a very limited scope and it actually is a bit of an anti pattern in that the class actually knows that the fields will be injected by some custom injector. You could argue the same about assisted injects - although those have a bit more broader use. Various other projects like Jukito/gwtmockito offer a possibility to "auto-mock" undefined bindings. So those could actually also use such an extension mechanism. On Mon, May 4, 2015 at 3:07 PM, Sam Berlin <[email protected]> wrote: > The lack of this feature is by design. See the discussion @ > https://github.com/google/guice/issues/49. > > sam > > On Mon, May 4, 2015 at 9:05 AM David Nouls <[email protected]> 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/d3e36ad3-c49b-4cbb-9640-6527877491bd%40googlegroups.com >> <https://groups.google.com/d/msgid/google-guice/d3e36ad3-c49b-4cbb-9640-6527877491bd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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/CAJEBNUeK-Ls%3DXZgP-h3gvg0KCGEuK%3Dp4ZTCtKBrThNHprGUT8w%40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CAJEBNUeK-Ls%3DXZgP-h3gvg0KCGEuK%3Dp4ZTCtKBrThNHprGUT8w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CABrJHW1Et3stENU-zq1CW7wEW1WE9WcxFbeBwB2dbxj3jOzTOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
