There's some performance overhead for having ProvisionListeners installed, but not much. I think most big servers here at have them installed, and we're getting along well with pretty high QPS on many of them. So it shouldn't be a big problem (unless, of course, you measure it to be a problem... and then you have some outs).
sam On Wed, Aug 21, 2013 at 4:20 PM, <[email protected]> wrote: > > If it's necessary to check for those types, then you could just have the >> matcher return 'true' always for provider bindings, and your onProvision >> method will be the same (because it already does the instanceof check). > > > Now I feel very stupid for not having thought of that! :-) > > Do you think it could lead of significative performance degradation to > always returning true there? > > Thanks for that clear explanation! > > > > On Wednesday, August 21, 2013 4:07:34 PM UTC-4, Sam Berlin wrote: > >> Hrm. It seems like your particular problem is because ProvisionListener >> is designed to notify you when a particular binding is provisioned, and the >> binding it supplies is the one for the exact thing being provisioned. So >> take this example: >> interface Foo {} >> class FooImpl implements Foo {} >> bind(Foo.class).to(FooImpl.**class); >> >> ... a ProvisionListener specifically for exact(Foo.class) will find >> nothing, because Foo is never provisioned. OTOH, a listener for >> exact(FooImpl.class) will match, because FooImpl is being provisioned. >> Even if someone is injecting Foo and not FooImpl. >> >> In your case, it's as-if the code was more like: >> interface Foo {} >> class FooImpl implements Foo, IInitableAfterCreation {} >> bind(Foo.class).toConstructor(**cxtorFor(FooImpl.class)); >> >> ... in that case, a listener for exact(Foo.class) *will* match, because >> that's the actual binding being provisioned -- it's not linked to any other >> binding. However, binding.getKey() will be Foo.class, which doesn't >> implement IInitableAfterCreation. But, the constructor that loads it is >> for a FooImpl, and FooImpl *does* implement the extra interface. That's >> why you need the extra matching. >> >> Off the top of my head, I can't think of any other kind of binding that >> would lead to the same scenario. Perhaps Providers, with something like: >> @Provides Foo provideFoo() { return new FooImpl(..); } >> .. with the same class setup as above, you'll be notified of a Foo >> binding, although Guice in this scenario has no way of knowing what the >> contents of the method are, so you can't use the same kind of code to >> detect for IInitableAfterCreation. (A normal toProvider binding would get >> the same effect if the contents of the get() method were the same.) >> >> If it's necessary to check for those types, then you could just have the >> matcher return 'true' always for provider bindings, and your onProvision >> method will be the same (because it already does the instanceof check). >> >> sam >> >> On Wed, Aug 21, 2013 at 3:54 PM, <[email protected]> wrote: >> >>> Thanks Sam. By reading about those SPI extensions, I found the way to >>> get the implementation type in the matches() method : >>> >>> https://gist.github.com/**electrotype/6299241<https://gist.github.com/electrotype/6299241> >>> >>> So it's now working! All my tests passed even with the >>> *IInitableAfterCreation >>> *interface set on the implementation classes. >>> >>> The only thing I'd like to be sure is if I do I have to check for other >>> kind of binders than *ConstructorBinding* for my bindListener to always >>> work? Or is this the only case where a direct *binding.getKey(). >>> getTypeLiteral().getRawType()* won't be the type that has to be >>> validated agains the *IInitableAfterCreation *interface? In my >>> application, for now, checking for *ConstructorBinding* seems to be >>> enough. >>> >>> >>> >>> >>> On Wednesday, August 21, 2013 2:18:55 PM UTC-4, Sam Berlin wrote: >>>> >>>> I think what Stuart is saying is that the Binding itself doesn't expose >>>> the info because, well, it doesn't have the info. You need to use >>>> theAssistedInject SPI >>>> extension<https://code.google.com/p/google-guice/wiki/AssistedInject#Inspecting_AssistedInject_Bindings_(new_in_Guice_3.0)>to >>>> get the info you want. The >>>> getAssistedMethod<http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/assistedinject/AssistedInjectBinding.html>method >>>> should expose the info you want in >>>> AssistedMethod<http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/inject/assistedinject/AssistedMethod.html> >>>> . >>>> >>>> sam >>>> >>>> ******** >>> >>> -- >>> 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 google-guice...@**googlegroups.com. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at >>> http://groups.google.com/**group/google-guice<http://groups.google.com/group/google-guice> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >> >> ******** > > -- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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. For more options, visit https://groups.google.com/groups/opt_out.
