Guice team,
Last year we expanded our SPI to expose rich details about modules and
injectors. The elements API can inspect, extend and even rewrite Guice
configuration. It's an essential tool used by GIN, Modules.override(),
Grapher, Guiceberry's controllable injection, and others.
Unfortunately, SPI coverage is currently limited to the Guice core.
Programmatic inspection of Multibindings, Assisted Inject, Servlets
and even provider methods aren't exposed via the SPI. It's time to
address this!
I'm rolling around two proposals as to how extensions will work in the
SPI and I'm looking for feedback. I've got a code example to
illustrate each approach. For each, the code prints all of an
injector's bindings, including deluxe formatting for Assisted Inject.
Once implemented, the full extensions SPI will be used to expose
information for many Guice extensions.
-----
A) client instanceof
public static void main(String[] args) {
Injector injector = Guice.createInjector(...);
for (Binding<?> binding : injector.getBindings().values()) {
System.out.println(binding.acceptTargetVisitor(new
DefaultBindingTargetVisitor<Object, String>() {
public String visit(ProviderInstanceBinding<?> binding) {
Provider<?> provider = binding.getProviderInstance();
if (provider instanceof FactoryProvider) {
FactoryProvider factoryProvider = (FactoryProvider)
provider;
return "Factory: " + binding.getKey()
+ " builds " + factoryProvider.getImplementationType
()
+ " using parameters " +
factoryProvider.getAssistedParameters();
}
return super.visit(binding);
}
protected String visitOther(Binding<?> binding) {
return binding.toString();
}
}));
}
}
The user implements the standard visit(ProviderInstanceBinding)
method. They're responsible for knowing what kind of binding(s)
Assisted Inject creates behind-the-scenes, and for doing an instanceof
on the bound provider. They implement only the BindingTargetVisitor
interface.
The extension author needs to document which bindings to look for, and
what instanceof call the user should perform.
-----
B) visitor subtypes
public static void main(String[] args) {
Injector injector = Guice.createInjector(new PorscheModule());
for (Binding<?> binding : injector.getBindings().values()) {
System.out.println(binding.acceptTargetVisitor(new
AssistedVisitor()));
}
}
static class AssistedVisitor extends
DefaultBindingTargetVisitor<Object, String>
implements AssistedBindingVisitor<Object, String> {
public String visit(FactoryProvider<Object> factoryProvider,
ProviderInstanceBinding<?> binding) {
return "Factory: " + binding.getKey()
+ " builds " + factoryProvider.getImplementationType()
+ " using parameters " +
factoryProvider.getAssistedParameters();
}
protected String visitOther(Binding<?> binding) {
return binding.toString();
}
}
The user implements a special interface for each extension that
they're interested in. It adds a new visit() method that's specific to
the extension. Because they must implement both the extension-
interface and the standard BindingTargetVisitor interface, this
approach can't easily be used with anonymous inner classes.
The extension author needs to write a special interface for their
visit method. The Guice core needs to expose hooks for extensions to
discover their specific visitor types, and the extension author must
use these hooks.
-----
There are quite a few Guice extensions, including some potentially
outside of the main Guice project (Warp, Guiceberry, GIN...). Does
anyone have a preference? Or a third proposal? Discussion is welcome.
Thanks.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
