On 3 June 2010 09:16, Pascal-Louis <[email protected]> wrote:
> Jesse,
>
> In practice, the dozen or so bindings are more like 50 or 100; and
> very fragile. Add one use of a proxy, and now you need to add this
> binding to all the entry points. (You might wonder why we don't have a
> common module with all of those. Many are singleton scoped and so we
> do not want to create them in systems that do not need them.)
>
FWIW there are alternative approaches that work with Guice today:
1) Use a factory to retrieve your marshalling objects...
//================================================
interface EntityMarshallerFactory
{
<T> EntityMarshaller<T> getMarshaller( Class<T> entityType );
}
//================================================
You could then @Inject an instance of EntityMarshallerFactory into
your code - maybe not as elegant as injecting the marshaller directly
but it works.
2) Inject a concrete parameterized class, not an interface...
//================================================
class JitProvider<T>
implements Provider<T>
{
@Inject
TypeLiteral<T> type;
public T get()
{
try
{
return (T) type.getRawType().newInstance();
}
catch ( IllegalAccessException e )
{
throw new RuntimeException( e );
}
catch ( InstantiationException e )
{
throw new RuntimeException( e );
}
}
}
class JitProviderExample<T>
{
@Inject
JitProvider<T> jitProvider;
}
public class Test
{
@Inject
void testJitProvider( JitProviderExample<String> example )
{
System.out.println( example.jitProvider.get().getClass() );
}
}
//================================================
This relies on the existing limited JIT capability that's in Guice today.
Downsides are that you can't easily swap implementations, it doesn't
play well with child injectors, plus the other JIT related issues Jesse
mentioned (can lead to too much magic).
3) Write a module that uses the Guice SPI to scan your application
bindings/types for mentions of EntityMarshaller<...> so it can bind
any missing bindings explicitly before the injector is created.
I'm using this technique at the moment with good results, also means
that you can use the Guice Grapher to visualize the whole application
because there aren't any JIT-related rabbit holes that the Grapher can't
follow down.
Downside is that this doesn't work with types that crop up at runtime,
ie. that aren't in the original application bindings/types used to create
the injector.
HTH
Since this has bitten us a lot in the past, we wanted to spend the
> time to replace this with a generic and robust solution.
>
> I'll do the improvements and report back. I'll also address Stuart's
> comments about whitespace edits and such to have a clean patch.
>
> PL
>
> On Jun 2, 5:35 pm, "[email protected]" <[email protected]> wrote:
> > On Jun 2, 7:41 am, Pascal-Louis <[email protected]> wrote:
> >
> > > Would that address your concerns?
> >
> > It would, but it still doesn't quite pay for its complexity.
> > Autobinders would let you replace something structurally simple but
> > verbose (a dozen or so repetitive bind() statements) with something
> > structurally complex but compact (some reflection to implement
> > JitProvider).
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice-dev" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-guice-dev%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-guice-dev?hl=en.
>
> --
Cheers, Stuart
--
You received this message because you are subscribed to the Google Groups
"google-guice-dev" 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-dev?hl=en.
