WARN logs in InterceptorRegistry

[jaikiran]

In the current version of EJB3 on JBoss-5.0GA, a bean method invocation always generates a lot of these WARN messages:

WARN [InterceptorRegistry] applicable interceptors is non-existent for .....

Looking at the InterceptorRegistry, i do see a TODO with some explanation:

public List<Class<?>> getApplicableInterceptorClasses(Method method)
 {
 List<Class<?>> methodApplicableInterceptorClasses = applicableInterceptorClasses.get(method);
 //TODO
 //FIXME: This assertion is valid, but EJB3 Core needs to declare virtual methods without interceptors
 // such that they make the Map of MethodHashes, and these then get improperly placed in the
 // Joinpoint Map, which ends up here...
 //assert methodApplicableInterceptorClasses != null : "applicable interceptors is non-existent for " + method;
 log.warn("applicable interceptors is non-existent for " + method);
...
}

1) Could we reduce the logging level to maybe DEBUG, since this message is not really for the end-user.

2) Is that logging message missing a if block? The earlier assert statement (which now is commented out) was checking whether the methodApplicableInterceptorClasses is null. The log message does not do this. Or is it that the methodApplicableInterceptorClasses is always null?

[wolfc]

Nice catch, it's missing an 'if'.

This needs to be properly fixed, so the assertion can take hold. We need to identify all scenarios in which methodApplicapleInterceptorClasses is null so we can come up with the proper fix.

[lutz.vahl]

something new..?

[jaikiran]

Workaround, if you want to avoid those logs from showing up:

<category name="org.jboss.ejb3.interceptors.registry.InterceptorRegistry">
 <priority value="ERROR"></priority>
</category>

in your jboss-log4j.xml

[jaikiran]

I have started work on fixing this. One of the issues (though not directly related) i see in this registry, is this:

Class<?> beanClass = advisor.getClazz();
 for(Method beanMethod : ClassHelper.getAllMethods(beanClass))
 {
 interceptorsAnnotation = (Interceptors) advisor.resolveAnnotation(beanMethod, Interceptors.class);
 List<Class<?>> methodInterceptorClasses = new ArrayList<Class<?>>();
 if(interceptorsAnnotation != null)
 {
 for(Class<?> interceptorClass : interceptorsAnnotation.value())
 methodInterceptorClasses.add(interceptorClass);
 }

...

From the EJB3 spec:

Interceptors are used to interpose on business method invocations and lifecycle events that occur on an enterprise bean instance.

So, using

ClassHelper.getAllMethods(beanClass)

doesn't look right.

[jaikiran]

"wolfc" wrote:

We need to identify all scenarios in which methodApplicapleInterceptorClasses is null so we can come up with the proper fix.

One of the simplest valid cases would be a bean having no Interceptor(s) declared:

@Stateless
public class SimpleBean implements NoInterceptor
{
 public void doNothing()
 {
 ....
 }

}

There wont be any interceptors applicable (i.e. methodApplicapleInterceptorClasses == null) for that business method.

This needs to be properly fixed, so the assertion can take hold

What is the use case where this assertion should hold? From the above example, i think its a valid scenario to have no interceptors applicable for a given method. Am i missing something?

[wolfc]

"EJB 3.0 Chapter 12" wrote:
Interceptors are used to interpose on business method invocations and lifecycle events that occur on an enterprise bean instance.

The keyword here is 'invocations'.
Let's just say that it's beyond the scope of InterceptorRegistry to identify business methods and that getApplicableInterceptorClasses assumes that the argument is a business method.

"jaikiran" wrote:
There wont be any interceptors applicable (i.e. methodApplicapleInterceptorClasses == null) for that business method.

methodApplicableInterceptorClasses must not be null, it must be an empty list.