Thanks for the info, I will try that approach. Sounds like fun. On Mon, May 4, 2015 at 9:28 PM, Vyacheslav Rusakov <[email protected]> wrote:
> I faced almost the same problem: I was writing a kind of spring-data > repositories, where queries supposed to be defined with annotations on > interface methods and in runtime proxies should be created. > > The solution I found is a bit hacky: I used @ProvidedBy with generic > provider, which could simply generate proxy class from provided interface. > It was important for me to generate proxy class, because guice aop doesn't > work for binded instances, and I was going to implement all annotations on > interfaces with aop (+reuse @Transactional logic). > > Detecting requested type in provider is possible, using internal guice > api: > https://github.com/xvik/guice-ext-annotations/blob/master/src/main/java/com/google/inject/internal/DynamicClassProvider.java > As a result, I can now simply annotate interface (or abstract class) with > @ProvidedBy(DynamicClassProvider.class) and it will generate required proxy > (using javassist) in runtime (during jit resolution) > > https://github.com/xvik/guice-ext-annotations#abstract-types-support > > I think, it perfectly fits for your case. You will just need to implement > @Alert annotation support with guice AOP. > Or you could write your own hacky provider the same way :) > > понедельник, 4 мая 2015 г., 20:40:09 UTC+6 пользователь Sam Berlin написал: >> >> The reason for the lack of feature is because it would make code using it >> harder to understand. There's a 1:1 ratio right now with bind statements >> (or @Provides methods) and injectable types right now. That's relaxed to >> 0:1 for just-in-time bindings (so if you don't see a bind statement for a >> type, it must be a just-in-time binding). Allowing 1:many would make >> understanding what is being injected much harder. Guice is already >> confusing enough... no need to add more features that complicate the basic >> injection model even more. >> >> TypeListeners are somewhat different because they require using different >> annotations. The rules for @Inject stay the same, but Guice can be >> leveraged to supply data to other annotations. >> >> sam >> >> On Mon, May 4, 2015, 9:54 AM David <[email protected]> wrote: >> >>> 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 >>> <https://groups.google.com/d/msgid/google-guice/CABrJHW1Et3stENU-zq1CW7wEW1WE9WcxFbeBwB2dbxj3jOzTOA%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/96cbe006-2f8d-4855-ad96-a50c3f69dac7%40googlegroups.com > <https://groups.google.com/d/msgid/google-guice/96cbe006-2f8d-4855-ad96-a50c3f69dac7%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/CABrJHW0qgVNKBnKs9fkS1fahfgdT9UjsZXPCH3KEnK5M_uBaJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
