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?
-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
-~----------~----~----~----~------~----~------~--~---
