interceptor that return void, unclear in 1.0 specification, needs clarification in 1.1
by Rick Hightower
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) throwsException {
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 <http://www.google.com/profiles/RichardHightower>
15 years
[JBoss JIRA] Commented: (CDI-50) Ability to veto beans, both unconditionally and based on classes visible
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-50:
----------------------------------
This goes in the same direction as CODIs @ProjectStageActivated and @PropertyActivated - it's just the other way around.
We have a n-staged lookup mechanism. You can either set the values via
* export MyProperty=myValue
* java .. -DMyProperty=myValue
* use a <context-param> in your web.xml
* use a JNDI value under java:/comp/env/myfaces-codi/MyProperty
depending on which environment is available (no JNDI -> no JNDI lookup; no servlet -> no context-param lookup, etc)
> Ability to veto beans, both unconditionally and based on classes visible
> ------------------------------------------------------------------------
>
> Key: CDI-50
> URL: https://issues.jboss.org/browse/CDI-50
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> This should support both a straight veto, and conditional based on classes available.
> Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}).
> Mark Struberg proposed using @Optional
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Updated: (CDI-50) Add annotation version of veto()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-50:
-------------------------
Description:
This should support both a straight veto, and conditional based on classes available.
Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}).
Mark Struberg proposed using @Optional
was:This should support both a straight veto, and conditional based on classes available
> Add annotation version of veto()
> ---------------------------------
>
> Key: CDI-50
> URL: https://issues.jboss.org/browse/CDI-50
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> This should support both a straight veto, and conditional based on classes available.
> Seam Solder supports this as @Veto and @Requires({Foo.class, Bar.class}).
> Mark Struberg proposed using @Optional
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ]
Arne Limburg commented on CDI-14:
---------------------------------
We cannot split the BeanManager more than in 1.0, but we can add new methods (like the method discussed here) somewhere else.
Mark, you can fire an event when you have an Instance<Object>:
{noformat}
Instance<Object> instance = ...
Event<MyEvent> event = instance.select(new TypeLiteral<Event<MyEvent>>() {}.getType()).get();
event.fire(...);
{noformat}
Since event is a bean, this should work.
> Add instance() method to BeanManager
> ------------------------------------
>
> Key: CDI-14
> URL: https://issues.jboss.org/browse/CDI-14
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> Currently obtaining a contextual reference is quite a complex operation, adding a method like:
> Instance<Object> instance();
> would make it much easier.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
CDI 1.1
by Peter Muir
Hi everyone
Welcome to the CDI 1.1 expert group. I've started to collect some resources at https://github.com/pmuir/cdi/wiki. Please take some time to read through them.
I would like everyone to work their way through the various lists of issues in JIRA https://github.com/pmuir/cdi/wiki/CDI-1.1-issues and do four things:
* If you are aware of an issue that is not recorded, please create one
* If you think an issue on the TBC list should be addressed in CDI 1.1 then please make a note of this, and prepare an email to this list explaining why you think the issue should be included. Please restrict yourself to three such issues.
* If you think an issue on the proposed list shouldn't be addressed then please make a note of this, and prepare an email to this list explaining why you think the issue shouldn't be included. Please restrict yourself to three such issues.
* Write a note to the list indicating what issues you are going to take a lead on. For major issues, prepare a 2 minute summary for the concall so that you can brief people on the issue.
The (soft) deadline for this exercise is Wednesday 11th May. Of course, we can continue to debate the merits of issues after this, but to make things run smoothly it will help a lot if we can get this done quickly!
I propose we have conference call on Thursday 12th May to kick off, overview the main issues facing us and run through who will take what issues. Here is my proposed slot - http://www.timeanddate.com/worldclock/fixedtime.html?msg=CDI+Kick+off+con... - it's difficult to find something suitable for everyone, but this does allow both people in Australia (late night) and the US West Coast (our two extremes) to particpate.
Any comments or suggestions welcome,
Pete
15 years
Git updates
by Pete Muir
All
I have updated the spec sources on github, changing the jsr299 folder name and adding the 1.1 api sources.
Both are under https://github.com/pmuir/cdi
I am also looking at moving this repo. I've asked the guy who owns /cdi if he can give it up, if not I will move this to the /jboss organisation.
Pete
15 years