> 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] <javascript:>> 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
>>
>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> 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.
