Reputation: 8746
I ran into this confusion today. Quote from Weld's documentation (right under Section 9.3),
By default, all interceptors are disabled. We need to enable our interceptor. We can do it using beans.xml descriptor of a bean archive. However, this activation only applies to the beans in that archive.
However, in the project that I am currently working on, I have an interceptor for profiling a method. My META-INF/beans.xml
is basically empty:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
version="1.1" bean-discovery-mode="all">
</beans>
Yet I still get expected logs from that profiling interceptor. So, as the title goes, is interceptor really disabled by default?
BTW, I use weld-se
for CDI functionality in the project, since CDI is the only thing I need for the project from the Java EE stack.
After messing around interceptors today, I find that if the old @Interceptors
is used to indicate the interception implementation class, you don't need to specify anything in the beans.xml
. However, if you use interceptor binding, i.e., use the @Interceptor
annotation to indicate an interceptor class, you must enable interception by adding the interceptor class to the beans.xml
. According to my experience, this is still true for CDI 1.1, as indicated by the version in the beans.xml
above. BTW, I use org.jboss.weld.se:weld-se:2.0.4.Final
for CDI implementation in this case, which I believe implements CDI 1.1.
Upvotes: 6
Views: 3564
Reputation: 3606
To confirm JBT findings in his EDIT. As per CDI specifications 1.0 of JSR-299 implemented by Weld 1.0 for JEE6 specs. Please reference this pointer, which I quote:
By default, a bean archive has no enabled interceptors bound via interceptor bindings. An interceptor must be explicitly enabled by listing the fully qualified class name in a child
<class>
element of<interceptors>
. as in Approach 2 below
Follows an example:
@InterceptorBinding
@Retention(RUNTIME)
@Target({METHOD, TYPE})
public @interface Loggable {
}
@Interceptor
@Loggable
public class LoggingInterceptor {
@AroundInvoke
public Object logMethodEntry(InvocationContext ctx) throws Exception{
System.out.println("In LoggingInterceptor..................... before method call");
Object returnMe = ctx.proceed();
System.out.println("In LoggingInterceptor..................... after method call");
return returnMe;
}
}
@Stateless
@Interceptors(LoggingInterceptor.class) //class interception
public class Displayer implements DisplayerLocal {
@Override
//@Interceptors(LoggingInterceptor.class) //method interception
public void displayHi() {
System.out.println(".....Hi there............");
}
}
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<interceptors>
<class>com.companyname.LoggingInterceptor</class>
</interceptors>
</beans>
Then the intercepted class:
@Stateless
@Loggable //class interception
public class Displayer implements DisplayerLocal {
@Override
//@Loggable //method interception
public void displayHi() {
System.out.println(".....Hi there............");
}
}
Upvotes: 9
Reputation: 27516
Interceptors and decorators are enabled from 1.1
version by default. See the highlights of the new CDI spec.
Upvotes: 1