dg wrote:
> Instead of
>
> binder().bind(new
> TypeLiteral<Provider<ResourceConverter<Icon>>>(){}).toInstance(new
> ConverterProvider<Icon>(Icon.class));
>
> try
>
> binder().bind(new
> TypeLiteral<ResourceConverter<Icon>>(){}).toProvider(new
> ConverterProvider<Icon>(Icon.class));
>
> Does that help?
>
Thanks for trying to help, dg.
Unfortunately this solution does not help.
That's what I did previously, that works well, except that, as I
mentioned, it doesn't prevent direct injection of
ResourceConverter<Icon>; what I wanted was to impose injection of
Provider<ResourceConverter<Icon>> and prevent direct injection.
I believe that binding of a Provider type to a Provider instance is just
simply forbidden by Guice 2.0
So I'll probably stick to my original solution (the one you just
mentioned!) and add bold comments in the javadoc, that only Provider
should be injected!
Cheers, Jean-Francois
> -d
>
>
> On Nov 9, 3:40 pm, Jean-Francois Poilpret <[email protected]> wrote:
>
>> Sam Berlin wrote:
>>
>>> I'm not sure I understand what you mean by, " I don't want to make it
>>> possible users of my library to directly inject ResourceConverter<T>
>>> into a class, but exclusively Provider<ResourceConverter<T>>".
>>>
>>> With Guice, if you say
>>>
>>> bind(Foo.class).toProvider(myFooProvider);
>>>
>>> and users can have both Foo & Provider<Foo> injected into their
>>> class. If the user opts to inject a Foo, it will be created by
>>> calling myFooProvider.get(). If a user opts to inject Provider<Foo>,
>>> then later get calls on that provider will call get on myFooProvider.
>>>
>>> Are you saying that you forcibly want to disallow users to inject
>>> Foo? If that's the case, your best bet is probably creating a
>>> separate custom interface called FooFactory and
>>> bind(FooFactory.class).toInstance(myFooFactory). (Still, I don't
>>> quite understand the rationale behind wanting to disallow direct
>>> injection of Foo.)
>>>
>> Thanks for your reply Sam. I won't go into the Factory direction because
>> it won't simplify the API.
>> The reason why I want to disallow direct injection is that, in my case,
>> it triggers recursive dependencies and ultimately fails (at runtime of
>> course).
>>
>> The fact is that I have many ResourceConverter<T> implementations, I put
>> them all in a MultiMap<TypeLiteral<?>, ResourceConverter<?>>, and most
>> importantly, some special ResourceConverter<T1> depend on
>> ResourceConverter<T2>, and that's where my problems began!
>>
>> My first solution to that problem was to create a Registry like that:
>>
>> interface ConverterRegistry {
>> public <T> ResourceConverter<T> getConverter(TypeLiteral<T> type);
>>
>> }
>>
>> The idea was to avoid injection Map<TypeLiteral<?>,...> which is
>> cumbersome code.
>> This worked well, but it obliges end-users to:
>> 1-get the registry
>> 2- do a lookup (getConverter()) every time they need access to some
>> ResourceConverter<T>
>>
>> Hence my idea of directly adding bindings (in addition to the MultiMap)
>> of ResourceConverter<T> to Providers that would do the lookup in the
>> Registry.
>> This worked fine as long as interested classes required the Provider
>> only (not the real object).
>>
>> Since then, I wanted to find a way to force my users to inject the
>> Provider<T> to avoid runtime exceptions with recursive dependencies.
>>
>> Is this clearer?
>>
>> As I said, I can still deal with this problem by pure documentation, but
>> that would have been better to prevent it in the first place.
>>
>> Cheers
>>
>> Jean-Francois
>>
>>
>>
>>
>>> Sam
>>>
>>> On Mon, Nov 9, 2009 at 10:47 AM, Jean-Francois Poilpret
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi,
>>>
>>> I am currently trying to bind Provider<T> to some instance of
>>> CustomProvider<T> (where T is a more complex, generic type).
>>> But I get "Binding to Provider is not allowed" when I create the
>>> Injector.
>>>
>>> Although my code is much more complex (I have a generic helper method
>>> that can do the following for any T type, not just Icon as in the
>>> example below), I think it boils down to the following:
>>>
>>> binder().bind(new
>>> TypeLiteral<Provider<ResourceConverter<Icon>>>(){}).toInstance(new
>>> ConverterProvider<Icon>(Icon.class));
>>>
>>> where:
>>>
>>> class ConverterProvider<T> implements Provider<ResourceConverter<T>>
>>> {
>>> ConverterProvider(TypeLiteral<T> type) {...}
>>> public ResourceConverter<T> get() {...}
>>> }
>>>
>>> I don't really understand why Guice doesn't allow binding to a
>>> Provider?
>>> Actually I don't bind TO a provider, but I bind A provider TO an
>>> instance of that type (ie Provider...)! That's not exactly the same!
>>>
>>> Actually, the reason why I do that is that I don't want to make it
>>> possible users of my library to directly inject ResourceConverter<T>
>>> into a class, but exclusively Provider<ResourceConverter<T>>;
>>> isn't that
>>> possible with Guice?
>>>
>>> If not, that's not a real blocking problem, it would just make my
>>> API a
>>> bit weaker than it has to (aand then I'll have to put more emphasis on
>>> the javadoc;-))
>>>
>>> Thanks in advance for any feedback
>>>
>>> Jean-Francois
>>>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
