[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir reopened CDI-274:
---------------------------
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-316) Adopt usage of the @since Javadoc tag
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-316?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-316:
--------------------------
Fix Version/s: 1.1 (Proposed)
> Adopt usage of the @since Javadoc tag
> -------------------------------------
>
> Key: CDI-316
> URL: https://issues.jboss.org/browse/CDI-316
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Javadoc and API
> Affects Versions: 1.1.PRD
> Reporter: George Gastaldi
> Fix For: 1.1 (Proposed)
>
>
> It's a good practice to use the @since javadoc tag in the methods and interfaces/classes created in this new version.
> This is necessary when one need to figure out if some feature is targeted to work in 1.1 only, for example.
> This issue was created so that all the API code can be reviewed before the next release. Some classes already have this information, other still don't (@Vetoed is one that is missing, afaik)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir closed CDI-274.
-------------------------
Fix Version/s: 1.1.PFD
(was: 1.1 (Proposed))
Resolution: Done
Marek actually opened a new issue - CDI-315
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-274:
--------------------------
Fix Version/s: 1.1 (Proposed)
(was: 1.1.PFD)
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-274) BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-274?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-274:
-------------------------------
application initialization includes ADV - this is a good point.
> BeanManager#getBeans() shall throw an Exception if called before AfterDeploymentValidation
> ------------------------------------------------------------------------------------------
>
> Key: CDI-274
> URL: https://issues.jboss.org/browse/CDI-274
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.EDR
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We recently had the erroneous case in DeltaSpike that an Extension did call BeanManager#getBeans() in an @Observes ProcessBean method.
> Doing so leads to random behaviour as the result of getBeans() depends on the order in which the other beans got processed already. E.g. getBeans(Object.class) will return an empty list for the first bean getting processed, and will return all beans -1 for the last bean. That just makes no sense and will create unreproducible bugs.
> PROPOSAL:
> We shall add spec language to BeanManager#getBeans() that any invocation before the AfterDeploymentValidation phase will result in a deployment error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-314) Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-314?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-314:
--------------------------
Fix Version/s: 1.1 (Proposed)
> Clarify behaviour if both a stereotype and a bean class is used to select/deselect an alternative bean
> ------------------------------------------------------------------------------------------------------
>
> Key: CDI-314
> URL: https://issues.jboss.org/browse/CDI-314
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.1.PRD
> Reporter: Martin Kouba
> Fix For: 1.1 (Proposed)
>
>
> In CDI 1.1 a bean which has {{@Alternative}} stereotype applied may be selected using the bean class. If both a stereotype and a bean class is used to select/deselect an alternative bean, conflicts may occur (in the cotext of CDI-18). E.g.:
> {code}
> @Stereotype
> @Alternative
> @Target({ TYPE, METHOD, FIELD })
> @Retention(RUNTIME)
> public @interface Mock {
> }
> @Mock
> class Foo {
> }
> <beans>
> <alternatives>
> <class priority="1000">org.mycompany.Foo</class>
> <stereotype priority="100">org.mycompany.Mock</stereotype>
> </alternatives>
> </beans>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (CDI-287) Clarify the order of CDI interceptors wrt. around-invoke method of target class
by David Blevins (JIRA)
[ https://issues.jboss.org/browse/CDI-287?page=com.atlassian.jira.plugin.sy... ]
David Blevins commented on CDI-287:
-----------------------------------
Checked TomEE and it looks like we also currently do 1) EJB, 2) BEAN, 3) CDI
Agreed that EJB, CDI, BEAN is more natural and what I would have expected we did.
> Clarify the order of CDI interceptors wrt. around-invoke method of target class
> -------------------------------------------------------------------------------
>
> Key: CDI-287
> URL: https://issues.jboss.org/browse/CDI-287
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Ron Šmeral
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> Currently, the CDI specification doesn't define, when is the around-invoke method of a target class called, with regard to CDI interceptors.
> The spec. only says, in 9.4, towards the end:
> bq. Interceptors declared using {{@Interceptors}} or in {{ejb-jar.xml}} are called before interceptors declared using interceptor bindings.
> Currently, the order happens to be (in EAP6):
> # {{@Interceptors}} and {{ejb-jar.xml}}
> # Around-invoke method
> # CDI interceptors
> In the following example the order of interception would be:
> # {{FirstInterceptor}}
> # {{SomeClass.aroundInvoke}}
> # {{ThirdInterceptor}}
> \\
> \\
> {code}
> public class SomeClass {
> @ThirdInterceptorBinding // bound to ThirdInterceptor
> @Interceptors(FirstInterceptor.class)
> public int doSomething() {
> // ...
> }
> @AroundInvoke // comes second
> public Object aroundInvoke(InvocationContext invocationContext) throws Exception {
> return invocationContext.proceed();
> }
> }
> {code}
> This problem manifests in this (currently skipped) test:
> https://github.com/weld/core/blob/1.1/tests-arquillian/src/test/java/org/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
Optional bean support in CDI : @Requires annotation
by Adrian Gonzalez
Hello,
If there's a better mailing list than cdi-dev for this kind of question, just let me know and sorry :)
A question about https://issues.jboss.org/browse/CDI-225.
I have a CDI jar using an optional jar. And CDI impl I use log an error [1] (the bean is then ignore and my webapp functions normally).
Problem is I have a lot of errors in console and I don't want to tell my users to change logging configuration each time they use my lib.
@Requires(com.filenet.api.constants.Cardinality.class.getName()) won't be available in CDI 1.1 what are my options ?
If I understood correctly :
1. Do nothing and hope cdi impl just log a warning and ignore the bean (this is the case for OWB and Weld)
-> this will be non-portable of course.
2. Change the current packaging
-> I will need to package each optional functionnality in its own jar in this case.
3. Create my own @Requires annotation and the corresponding extension
-> I don't think it's doable since CDI impl will have to build the AnnotatedType before my extension can veto or add @Veto (and even then adding @Veto will be too late)
No more options ?
If not and 2 is the only working portable solution, is it possible to reopen CDI-225 ?
It's quite strange IMO to have CDI force a packaging decision.
Some libraries are not packaged with this logic (i.e. spring-orm has a lot of optionnal dependencies - i.e for hibernate 3, hibernate 4, jdo, jpa).
Thanks for your help and sorry for the long mail
[1]
Error with Weld (JBoss 7.1.0)
15:28:18,490 INFO
[org.jboss.weld.ClassLoading] (MSC service thread 1-4) catching: org.jboss.weld.resources.spi.ResourceLoadingException: Error loading
class com.natixis.sphinx.jsf.filenet.ged.SessionMetadata$PropertyMetadata
at
org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:152)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:86)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:115)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:171)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:336)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at
org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
[jboss-as-weld-7.1.0.Final.jar:7.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_24]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24]
Caused by: java.lang.NoClassDefFoundError:
Lcom/filenet/api/constants/Cardinality;
at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.6.0_24]
at
java.lang.Class.privateGetDeclaredFields(Class.java:2291)
[rt.jar:1.6.0_24]
at java.lang.Class.getDeclaredFields(Class.java:1743) [rt.jar:1.6.0_24]
at
org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:102) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:63) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:99) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:153) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:118)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:49) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:40) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:355) [guava-11.0.2.jar:]
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184) [guava-11.0.2.jar:]
at
com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153) [guava-11.0.2.jar:]
at
com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69) [guava-11.0.2.jar:]
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:393) [guava-11.0.2.jar:]
at
org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:149)
[weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
... 11 more
Caused by: java.lang.ClassNotFoundException: com.filenet.api.constants.Cardinality from [Module
"deployment.test-cdi-web.war:main" from Service Module Loader]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
... 29 more
Error with Websphere 8.0.x :
6/01/13 16:45:09:504 CET] 0000000e InjectionProc W CWNEN0047W: Les annotations de ressource pour les champs de la classe com.natixis.sphinx.jsf.filenet.ged.SessionMetadata$PropertyMetadata seront ignorées. Ces annotations n'ont pas pu être obtenues en raison de l'exception suivante : java.lang.NoClassDefFoundError: com.filenet.api.constants.Cardinality
at java.lang.Class.getDeclaredFieldsImpl(Native Method)
at java.lang.Class.getDeclaredFields(Class.java:546)
at com.ibm.wsspi.injectionengine.InjectionProcessor.getAllDeclaredFields(InjectionProcessor.java:569)
at com.ibm.wsspi.injectionengine.InjectionProcessor.processAllAnnotations(InjectionProcessor.java:741)
at com.ibm.ws.injectionengine.AbstractInjectionEngine.processAnnotations(AbstractInjectionEngine.java:684)
at com.ibm.ws.injectionengine.AbstractInjectionEngine.processInjectionMetaData(AbstractInjectionEngine.java:457)
at com.ibm.ws.injectionengine.AbstractInjectionEngine.processInjectionMetaData(AbstractInjectionEngine.java:380)
at com.ibm.ws.webbeans.services.ResourceInjectionServiceImpl.initialize(ResourceInjectionServiceImpl.java:103)
at com.ibm.ws.webbeans.services.JCDIComponentImpl.deployedObjectStart(JCDIComponentImpl.java:327)
at com.ibm.ws.webbeans.services.JCDIComponentImpl.stateChanged(JCDIComponentImpl.java:389)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.stateChanged(ApplicationMgrImpl.java:1105)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.fireDeployedObjectEvent(DeployedApplicationImpl.java:1352)
at com.ibm.ws.runtime.component.DeployedModuleImpl.setState(DeployedModuleImpl.java:247)
at com.ibm.ws.runtime.component.DeployedModuleImpl.start(DeployedModuleImpl.java:635)
at com.ibm.ws.runtime.component.DeployedApplicationImpl.start(DeployedApplicationImpl.java:967)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.startApplication(ApplicationMgrImpl.java:766)
at com.ibm.ws.runtime.component.ApplicationMgrImpl.start(ApplicationMgrImpl.java:2153)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:445)
at com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:123)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:388)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl.access$500(CompositionUnitMgrImpl.java:116)
at com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:994)
at com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:349)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1659)
Caused by: java.lang.ClassNotFoundException: com.filenet.api.constants.Cardinality
at java.net.URLClassLoader.findClass(URLClassLoader.java:434)
at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:198)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:665)
at java.lang.ClassLoader.loadClass(ClassLoader.java:644)
at com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:113)
at java.lang.ClassLoader.loadClass(ClassLoader.java:627)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:62)
at com.ibm.ws.classloader.ProtectionClassLoader.loadClass(ProtectionClassLoader.java:58)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:565)
at java.lang.ClassLoader.loadClass(ClassLoader.java:627)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:565)
at java.lang.ClassLoader.loadClass(ClassLoader.java:627)
... 24 more
11 years, 3 months