In the second case, this ultimately means that Weld will check
whether doSomething(Object) is intercepted. It isn't, since
Beans.getInterceptableMethods() is ignoring bridge methods. The
interceptor will not be invoked. On the other hand, in the first
case, the interceptor _will_ be invoked, since Weld will be
checking whether doSomething(String) is intercepted.
My initial solution was to make Beans.getInterceptableMethods()
also return bridge methods, but now I'm thinking the actual
problem is in the proxy itself. IMO, when creating a proxy based
on an interface, we should also generate bridge methods on the
proxy (this should be either done by Weld or by Javassist
directly). These bridge methods should be perfectly normal bridge
methods and should not invoke the method handler directly. They
should simply invoke the non-bridge method and the non-bridge
method should then invoke the method handler.
The java compiler can't add bridge methods directly to interfaces
which require them, so it adds them to all the classes
implementing the interface (StringFooImpl in our case). Since we
are creating StringFoo$Proxy, which is also a class implementing
an interface which requires bridge methods, we should add the
bridge methods
to it - exactly as the java compiler would.
This would solve the interceptor problem and possibly other
similar problems as well.
Marko