When is aopalliance.jar needed?

[pascallo...@gmail.com]

I'm trying to inject things into a module

Module m = ...
injector1 = ...
injector1.injectMembers(m);

if the module instance m is a simple implementation of the Module
interface, everything works fine. But if is extends AbstractModule so
AOP classes are needed. What explains this behavior? Should I include
the jar even if I'm not planning on using the AOP functionalities?

Thanks.
PL

[Dhanji R. Prasanna]

The Binder.bindInterceptor() method, which AbstractModule exposes,
takes aopalliance artifacts as an argument. So you do need it in the
classpath.

What you could do instead is build yourself a version of guice with
that method removed, or simply write a dummy
org.aopalliance.intercept.MethodInterceptor and
org.aopalliance.intercept.MethodInvocation in your source code.

So long as you don't bind any interceptors it should not need to load
any other classes from aopalliance.jar. Really it's a small enough jar
that it shouldn't matter.

Dhanji.

[Bob Lee]

Yeah, it sounds like AbstractModule is forcing the AOP Alliance interface to load some how. To be on the safe side, I would always include the jar. It only contains interfaces. Maybe I should just bundle it with the Guice jar in the next release?

Bob

[Robbie Vanbrabant]

It's because of injectMembers in this case. For example:
public class GuiceTest {
    public static void main(String[] args) {
        Injector i = Guice.createInjector();
        i.injectMembers(new AbstractModule(){
            @Override
            protected void configure() {}
        });
    }
}

Gives:
Exception in thread "main" java.lang.NoClassDefFoundError: [Lorg/aopalliance/intercept/MethodInterceptor;
    at java.lang.Class.getDeclaredMethods0(Native Method)
    at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
    at java.lang.Class.getDeclaredMethods(Class.java:1791)
    at com.google.inject.InjectorImpl.addInjectors (InjectorImpl.java:351)

And so on. I had the same problem when using Jython with Guice, now that I think of it.
I'd just add to the the javadoc and the user guide that this could happen. Perhaps we could consider creating a version of AbstractModule that doesn't trigger the error. SafeAbstractModule or something. Don't know. I'm not really a fan of adding it to the jar (different package: compatitbility, same package: other global classloading issues).

Robbie