[cdi-dev] interceptor that return void, unclear in 1.0 specification, needs clarification in 1.1

[Marius Bogoevici]

----- Original Message -----

From: "Jaikiran Pai" <jpai at redhat.com> 
To: "Marius Bogoevici" <mariusb at redhat.com> 
Cc: cdi-dev at lists.jboss.org 
Sent: Monday, May 16, 2011 3:18:16 AM 
Subject: Re: [cdi-dev] interceptor that return void, unclear in 1.0 specification, needs clarification in 1.1 

On Monday 16 May 2011 12:44 PM, Marius Bogoevici wrote: 


Weld will issue a warning when processing interceptors, indicating that the method does not meet the criteria for being considered an interceptor method. 

The plan is to actually throw a deployment exception in the future (there's a WELD issue for that). One of the problems of the interceptors specification is that it does not indicate when the container should throw a deployment error (in the same way as for example the CDI specification does), it just says what should be considered an interceptor method. So it's basically an issue of deciding for yourself whether you want to be "lenient and confusing" vs "unforgiving". 


IMO, if a target bean is specifically marking an interceptor (via @Interceptors) and that interceptor is having some incorrect construct, then I guess it makes sense to fail the deployment. After all, that interceptor is unusable and ultimately will have an impact on the bean operations. 

That's the general idea. There are, however, some ambiguities regarding lifecycle interceptor methods - see CDI-82. 

-Jaikiran 

<blockquote>


----- Original Message -----

From: "Jaikiran Pai" <jpai at redhat.com> 
To: cdi-dev at lists.jboss.org 
Sent: Monday, May 16, 2011 2:58:50 AM 
Subject: Re: [cdi-dev] interceptor that return void, unclear in 1.0 specification, needs clarification in 1.1 

The interceptors spec says this about @AroundInvoke methods on interceptors: 

<quote> 
Around-invoke methods have the following signature: 

Object <METHOD>(InvocationContext) throws Exception 

</quote> 

By the way, if Weld is failing silently, then I guess it needs to be improved to throw an explicit error. 

-Jaikiran 
On Monday 16 May 2011 12:06 PM, Rick Hightower wrote: 
<blockquote>

The specification has an example in 9.5.1 that returns a void. AspectJ/AspectWerks annotation allow this (prior art). 



Can interceptors return void? The specification seem unclear on this. Well, it shows an example but there is no further verbiage. 





I get three different behaviors for this interceptor: 


package org.cdi.advocacy.security; 






import javax.inject.Inject; 
import javax.interceptor.AroundInvoke; 
import javax.interceptor.Interceptor; 
import javax.interceptor.InvocationContext; 


/** 
* @author Richard Hightower 
*/ 
@Secure @Interceptor 
public class SecurityAdvice { 

@Inject 
private SecurityService securityManager ; 


@AroundInvoke 
public void checkSecurity(InvocationContext joinPoint) throws Exception { 

System. out .println( "In SecurityAdvice" ); 

/* If the user is not logged in, don't let them use this method */ 
if (! securityManager .isLoggedIn()){ 
throw new SecurityViolationException(); 
} 


/* Get the name of the method being invoked. */ 
String operationName = joinPoint.getMethod().getName(); 
/* Get the name of the object being invoked. */ 
String objectName = joinPoint.getTarget().getClass().getName(); 




/* 
* Invoke the method or next Interceptor in the list, 
* if the current user is allowed. 
*/ 
if (! securityManager .isAllowed(objectName, operationName)){ 
throw new SecurityViolationException(); 
} 

joinPoint.proceed(); 
} 
} 


Weld does not recognize it because it returns void. It fails silently. 
Candi recognizes it and uses it. 
OpenWebBeans throws an exception as follows: 






org.apache.webbeans.exception.WebBeansConfigurationException : @AroundInvoke annotated method : checkSecurity in class : org.cdi.advocacy.security.SecurityAdvice must return Object type 
at org.apache.webbeans.util.WebBeansUtil.checkAroundInvokeAnnotationCriterias( WebBeansUtil.java:1094 ) 
at org.apache.webbeans.util.WebBeansUtil.configureInterceptorMethods( WebBeansUtil.java:1241 ) 
at org.apache.webbeans.intercept.WebBeansInterceptorConfig.addMethodInterceptors( WebBeansInterceptorConfig.java:349 ) 
at org.apache.webbeans.intercept.WebBeansInterceptorConfig.configure( WebBeansInterceptorConfig.java:250 ) 
at org.apache.webbeans.config.DefinitionUtil.defineBeanInterceptorStack( DefinitionUtil.java:1058 ) 
at org.apache.webbeans.config.BeansDeployer.validate( BeansDeployer.java:365 ) 
at org.apache.webbeans.config.BeansDeployer.validateInjectionPoints( BeansDeployer.java:326 ) 
at org.apache.webbeans.config.BeansDeployer.deploy( BeansDeployer.java:179 ) 
at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication( AbstractLifeCycle.java:123 ) 
at org.cdiadvocate.beancontainer.OpenWebBeansBeanContainer.doStart( OpenWebBeansBeanContainer.java:26 ) 
at org.cdiadvocate.beancontainer.AbstractBeanContainer.start( AbstractBeanContainer.java:111 ) 
at org.cdi.advocacy.AtmMain.<clinit>( AtmMain.java:25 ) 
Exception in thread "main" java.lang.ExceptionInInitializerError 
Caused by: org.cdiadvocate.beancontainer.BeanContainerInitializationException : Unable to start BeanContainer : @AroundInvoke annotated method : checkSecurity in class : org.cdi.advocacy.security.SecurityAdvice must return Object type 
at org.cdiadvocate.beancontainer.AbstractBeanContainer.start( AbstractBeanContainer.java:113 ) 
at org.cdi.advocacy.AtmMain.<clinit>( AtmMain.java:25 ) 
Caused by: org.apache.webbeans.exception.WebBeansConfigurationException : @AroundInvoke annotated method : checkSecurity in class : org.cdi.advocacy.security.SecurityAdvice must return Object type 
at org.apache.webbeans.util.WebBeansUtil.checkAroundInvokeAnnotationCriterias( WebBeansUtil.java:1094 ) 
at org.apache.webbeans.util.WebBeansUtil.configureInterceptorMethods( WebBeansUtil.java:1241 ) 
at org.apache.webbeans.intercept.WebBeansInterceptorConfig.addMethodInterceptors( WebBeansInterceptorConfig.java:349 ) 
at org.apache.webbeans.intercept.WebBeansInterceptorConfig.configure( WebBeansInterceptorConfig.java:250 ) 
at org.apache.webbeans.config.DefinitionUtil.defineBeanInterceptorStack( DefinitionUtil.java:1058 ) 
at org.apache.webbeans.config.BeansDeployer.validate( BeansDeployer.java:365 ) 
at org.apache.webbeans.config.BeansDeployer.validateInjectionPoints( BeansDeployer.java:326 ) 
at org.apache.webbeans.config.BeansDeployer.deploy( BeansDeployer.java:179 ) 
at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication( AbstractLifeCycle.java:123 ) 
at org.cdiadvocate.beancontainer.OpenWebBeansBeanContainer.doStart( OpenWebBeansBeanContainer.java:26 ) 
at org.cdiadvocate.beancontainer.AbstractBeanContainer.start( AbstractBeanContainer.java:111 ) 
... 1 more 


I think CDI 1.1 should clarify the behavior and I think it should support return types of void. -- 
Rick Hightower 
(415) 968-9037 
Profile 

_______________________________________________
cdi-dev mailing list cdi-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev 
</blockquote>


_______________________________________________ 
cdi-dev mailing list 
cdi-dev at lists.jboss.org 
https://lists.jboss.org/mailman/listinfo/cdi-dev 


</blockquote>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20110516/755f69c0/attachment-0001.html