May 2011 - cdi-dev - Jboss List Archives

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>

14 years, 10 months

5
8
0 / 0

[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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-50) Ability to veto beans, both unconditionally and based on classes visible

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-50: ------------------------- Summary: Ability to veto beans, both unconditionally and based on classes visible (was: Ability to veto beans, both unconditionally and based on classes available) > 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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (CDI-50) Ability to veto beans, both unconditionally and based on classes available

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-50?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-50: ------------------------- Summary: Ability to veto beans, both unconditionally and based on classes available (was: Add annotation version of veto() ) > Ability to veto beans, both unconditionally and based on classes available > -------------------------------------------------------------------------- > > 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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (CDI-35) add support for 'optional' beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-35?page=com.atlassian.jira.plugin.sys... ] Pete Muir closed CDI-35. ------------------------ Assignee: Pete Muir Fix Version/s: (was: TBD) Resolution: Duplicate Issue > add support for 'optional' beans > -------------------------------- > > Key: CDI-35 > URL: https://issues.jboss.org/browse/CDI-35 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > > sometimes it's neat to mark a bean as @Optional depending if a specified class can get loaded or not. > This is a simple way to implement deployment specific functionality. > An example would be a BvalSupportBean which only should become active if the JSR-303 bean validation API can be found on the classpath. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[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

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-35) add support for 'optional' beans

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-35?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-35: ---------------------------------- The documentation for Seam3 @Required can be found here: http://docs.jboss.org/seam/3/solder/latest/api/org/jboss/seam/solder/core... > add support for 'optional' beans > -------------------------------- > > Key: CDI-35 > URL: https://issues.jboss.org/browse/CDI-35 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Packaging and Deployment > Affects Versions: 1.0 > Reporter: Mark Struberg > Assignee: Pete Muir > > sometimes it's neat to mark a bean as @Optional depending if a specified class can get loaded or not. > This is a simple way to implement deployment specific functionality. > An example would be a BvalSupportBean which only should become active if the JSR-303 bean validation API can be found on the classpath. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[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

14 years, 10 months

1
0
0 / 0

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

14 years, 10 months

4
14
0 / 0

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

14 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2011