The lack of notification for linked bindings is by design.
ProvisionListener only notifies things that are provisioned (essentially
the right hand side of any linked binding).

This does have a bad side effect of dropping some scoped notifications,
though, and folks probably aren't expecting that. I had thought it was
mentioned in the javadocs, but looks like it isn't.

At the very least, I can mention it in the docs.  I'm less enthused about
notifying on linked bindings too, but maybe that's not so terrible.

sam

On Wed, Nov 4, 2015, 5:05 AM jwa <[email protected]> wrote:

> I have come up with a solution that allows me to find all of the Singleton
> bindings in the module using the bind(...).in(Singleton.class) using the
> SPI mechanisms for introspecting a *Module* and not an *Injector*.
>
> To modify my previous example code:
>
> AbstractModule mod = new AbstractModule() {
>
>   @Override
>   protected void configure() {
>     bind(Vehicle.class).to(Car.class).in(Singleton.class);
>   }
>
> };
>
> Elements.getElements(mod).forEach((e) -> {
>   e.acceptVisitor(new DefaultElementVisitor<Void>() {
>       public <T> Void visit(Binding<T> binding) {
>         if (Scopes.isSingleton(binding)) {
>           System.out.println(binding.getKey() + " is singleton = " +
> Scopes.isSingleton(binding));
>         }
>         return null;
>       }
>   });
> });
>
>
> This correctly observes that the binding of Vehicle is a singleton:
>
> Key[type=com.instinet.gtr.cucumber.caas.di.TestGuice$Vehicle,
> annotation=[none]] is singleton = true
>
>
>
>
>
> On Wednesday, 4 November 2015 09:13:02 UTC, jwa wrote:
>>
>> Thomas - Having re-read your response I understand what you are alluding
>> to; the two-liner you are suggesting makes the Car a singleton within the
>> Injector. I can confirm that if I change the binding to your suggested
>> two-liner it does indeed note the provisioned Car is a singleton, i.e.
>>
>> bind(Vehicle.class).to(Car.class);
>> bind(Car.class).in(Singleton.class);
>>
>> Will output:
>>
>> Key[type=com.instinet.gtr.cucumber.caas.di.TestGuice$Car,
>> annotation=[none]] is singleton = true
>>
>>
>> However, that is not functionally equivalent to my previous module
>> configuration. I am happy for multiple Cars to exist in the system, I
>> simply want every instance of Car that is injected to fulfill Vehicle to
>> use the same instance.
>>
>> ---
>>
>> Using the TypeListener and ProvisionListener SPI mechanisms I am unable
>> to observe any information about Vehicle, I am only notified about the type
>> Car. Therefore, it seems impossible to observe the fact that the binding of
>> Vehicle is within Singleton scope?
>>
>> @opn - A valid point, I hadn't considered the syntactic sugar I could
>> offer with my own domain-specific abstract module. That's an idea which is
>> useful in numerous places.
>>
>> Thanks Again.
>>
>>
>>
>>
>>
>>
>>
>> On Wednesday, 4 November 2015 08:05:55 UTC, opn wrote:
>>>
>>> Also, the modules I'm consuming are provided by application developers
>>> who use my framework. I've published in the API they need to produce Guice
>>> modules. I'm not willing to be more restrictive and tell them to use
>>> specific syntax, that would reflect poorly on my framework.
>>>
>>> You could provide an abstract Guice module to hide the tedious binding
>>> procedure from developers using your framework. See for example:
>>>
>>>
>>> https://github.com/ArcBees/GWTP/blob/master/gwtp-core/gwtp-mvp-client/src/main/java/com/gwtplatform/mvp/client/gin/AbstractPresenterModule.java#L49
>>>
>>> On 11/04/2015 12:11 AM, Jamie Astin wrote:
>>>
>>> Hi Thomas,
>>>
>>> Thanks for taking the time to reply. The output posted is the total
>>> output from my test.
>>>
>>> Therefore, Guice is only observing one provision. Thus, its not like
>>> theres a second provision I could inspect.
>>>
>>> Also, the modules I'm consuming are provided by application developers
>>> who use my framework. I've published in the API they need to produce Guice
>>> modules. I'm not willing to be more restrictive and tell them to use
>>> specific syntax, that would reflect poorly on my framework.
>>>
>>> If the two separate bindings do work, this surely suggests a Guice bug?
>>> As far as I can tell your two-liner should be functionally equivalent to my
>>> on-liner?
>>>
>>> I'll try the two-liner tomorrow. My intention would be to debug + raise
>>> a bug / pull request if it actually fixes the underlying problem... Unless
>>> someone can explain the disparity between the one/two-liner?
>>>
>>> Thanks again!
>>>
>>>
>>> On Nov 3, 2015 21:17, "Thomas Broyer" <[email protected]> wrote:
>>>
>>>> The Car binding isn't a Singleton; the Vehicle one is. Using separate
>>>> bind() calls might do what you want:
>>>>
>>>>
>>>>
>>>> bind(Vehicle.class).to(Car.class);
>>>>
>>>> bind(Car.class).in(Singleton.class);
>>>>
>>>>
>>>>
>>>> (I don't know listeners much so can't really help beyond the above)
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "google-guice" group.
>>>>
>>>> To unsubscribe from this topic, visit
>>>> <https://groups.google.com/d/topic/google-guice/c2Gt_ABD7cQ/unsubscribe>
>>>> https://groups.google.com/d/topic/google-guice/c2Gt_ABD7cQ/unsubscribe.
>>>>
>>>> To unsubscribe from this group and all its topics, 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/b0d87ebc-b473-4b1b-97da-ec85f5755b5a%40googlegroups.com>
>>>> https://groups.google.com/d/msgid/google-guice/b0d87ebc-b473-4b1b-97da-ec85f5755b5a%40googlegroups.com
>>>> .
>>>>
>>>> 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/CACyC%2BgJXxxM%3Dk-i10dDyxROigYPv_Dm_72_qT7GqBP5Y3pnfxw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> https://groups.google.com/d/msgid/google-guice/CACyC%2BgJXxxM%3Dk-i10dDyxROigYPv_Dm_72_qT7GqBP5Y3pnfxw%40mail.gmail.com
>>> .
>>>
>>> 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/18c94b93-299b-4bd4-88cd-dff3c56d44c9%40googlegroups.com
> <https://groups.google.com/d/msgid/google-guice/18c94b93-299b-4bd4-88cd-dff3c56d44c9%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/CAJEBNUcsxRJ85qeeTarMedV%2BUTQp_gPWmaQpQr%2Bqk2LDGh34Wg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to