Seeking feedback on the new SPI...

[limpb...@gmail.com]

The new Guice 2 SPI is ready for your feedback.
The Service Provider Interface exposes Guice
internal models to aid in the development in
tools, extensions, and plugins.

Development Story...

This package was built by unifying two
independently developed APIs: Guice Commands
and the injector SPI.

Guice Commands was written to introspect,
rewrite, and validate modules. If you consider a
module to be your injector's source code, then
commands is kind of like static analysis and
code-rewriting -- stuff you do with a compiler
and AST.
http://publicobject.com/2008/02/guice-commands.html

The Injector API was written to inspect
the bindings of an already-built injector. It
gave access to the bindings, and their
dependency graph. If you consider a module
to be your injector's source code, then the
injector API is kind of like reflection -- stuff
you do at runtime.

Motivation...

The new SPI works with the elements of
both Modules and Injectors. It's intended
to give it's users full access to everything
they might need to know. And for the
Modules SPI, it also gives you the ability
to compose new modules from old ones.

At the same time, I want something that's
fairly small and easy enough to code
against. This code snippet logs a warning
for each static injection in your Modules:

public void warnOfStaticInjections(Module... modules) {
for (Element element : Elements.getElements(modules)) {
element.acceptVisitor(new DefaultElementVisitor<Void>() {
@Override
public Void visitStaticInjectionRequest(StaticInjectionRequest
element) {
logger.warning("Static injection is fragile! Please fix "
+ element.getType().getName() + " at " +
element.getSource());
return null;
}
});
}
}

The SPI leans a lot on the visitor pattern,
which I admit is not for everyone.

Please comment...

Grab the latest Guice snapshot from SVN
and take the new SPI for a spin. I wanna
make sure there's no problems in it before
the 2.0 release.
svn checkout http://google-guice.googlecode.com/svn/trunk/ google-
guice-read-only

Alternately, running through the Javadocs
might give you a feel for the package:
http://google-guice.googlecode.com/svn/trunk/latest-javadoc/com/google/inject/spi/package-summary.html
Note that the Javadoc still needs some
love -- but if there's ideas or suggestions
you have for the docs that's welcome as
well.

Thanks,
Jesse

[Alen Vrečko]

Hi,

Great stuff! I gave it a go with ModuleRewriter that automatically
adds a requestInjection for every interceptor that is bound. Simple.

ModuleWriter rewriter = new ModuleWriter() {
public void writeBindInterceptor(Binder binder,
InterceptorBinding interceptorBinding) {
super.writeBindInterceptor(binder,
interceptorBinding);
for (MethodInterceptor interceptor :
interceptorBinding.getInterceptors()) {
binder.requestInjection(interceptor);
}
}
};


Using the Binder from the param feels just like writing a plain
module.

Some wishes:

o) The ModuleWriter#create could also take existing module as param
instead of Elements so you don't see Element(s) at all. Or am I
missing something?

rewriter.create(Elements.getElements(myModule)) ->
rewriter.create(myModule)

o) In JavaDocs there could be some simple code snippets. When I saw
the unit test (ModuleRewriterTest) it made instant sense. Reading just
the method descriptions not so instant.

In any case, this SPI feels very intuitive.

Cheers,
Alen

[Brian]

Does this new SPI let me do this?
http://groups.google.com/group/google-guice/browse_thread/thread/8d0a950cf9cd2da8/fc60b5631a15db41

>  http://google-guice.googlecode.com/svn/trunk/latest-javadoc/com/googl...

[limpb...@gmail.com]

On Sep 7, 10:13 am, Brian <medo...@gmail.com> wrote:
> Does this new SPI let me do this?http://groups.google.com/group/google-guice/browse_thread/thread/8d0a...

No, it won't let you build bindings just-in-time
based on the injection point.

This is something that we're frequently tempted
to support, but it seems too dynamic. It might
lend itself to hard-to-maintain applications - we
want lots of type safety and runtime binding
generation works against this.

But there's another new API that might be able
to get you close. You can use the new
InjectionPoint class to discover which binding
annotations are requested for a given type. If
you have a single entry point class, this might
do what you need:
http://google-guice.googlecode.com/svn/trunk/latest-javadoc/com/google/inject/spi/InjectionPoint.html

Cheers,
Jesse