November 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-574: ---------------------------------- bq. The spec pretty imo clearly states that only enabled specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled... In this particular use-case the specialized bean is enabled in one bean archive and disabled in the second bean archive. > Should a disabled @Specialized disable a second bean? > ----------------------------------------------------- > > Key: CDI-574 > URL: https://issues.jboss.org/browse/CDI-574 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI specification Section 4.3: > When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. > The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? > Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. > This needs to be clarified. > In more details: > I have an application containing two wars. > testDiffBDA.war > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class > @Inject CounterProducerConsumerModified2 bean; > beans-xml-modified2.jar > containing one bean and an empty-ish beans.xml : > @Inject@CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > <alternatives> > <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> > </alternatives> > My application failed deployment with the error on Weld but worked on OpenWebBeans > {code} > [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier > at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer > at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) > {code} > After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. > From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-574: ----------------------------------- The spec pretty imo clearly states that *only* _enabled_ specialized beans do disable other beans. If this bean having the @Specializes annotation is itself disabled (because it is not an enabled alternative) then it does not disable the original bean. There is not even a 'non porbable behaviour results' section for it. > Should a disabled @Specialized disable a second bean? > ----------------------------------------------------- > > Key: CDI-574 > URL: https://issues.jboss.org/browse/CDI-574 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI specification Section 4.3: > When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. > The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? > Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. > This needs to be clarified. > In more details: > I have an application containing two wars. > testDiffBDA.war > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class > @Inject CounterProducerConsumerModified2 bean; > beans-xml-modified2.jar > containing one bean and an empty-ish beans.xml : > @Inject@CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > <alternatives> > <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> > </alternatives> > My application failed deployment with the error on Weld but worked on OpenWebBeans > {code} > [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier > at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer > at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) > {code} > After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. > From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-574: ------------------------------------------ Sorry Emily. I understand roughly your question, but could you detail your use case. You're talking about producer, there is not code for them. I don't understand where the CounterProducerConsumerModified2 bean is defined. >From here it looks like a corner case, but I may be wrong. Could you format your code and add your whole example. Thx. > Should a disabled @Specialized disable a second bean? > ----------------------------------------------------- > > Key: CDI-574 > URL: https://issues.jboss.org/browse/CDI-574 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI specification Section 4.3: > When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. > The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? > Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. > This needs to be clarified. > In more details: > I have an application containing two wars. > testDiffBDA.war > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class > @Inject CounterProducerConsumerModified2 bean; > beans-xml-modified2.jar > containing one bean and an empty-ish beans.xml : > @Inject@CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > <alternatives> > <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> > </alternatives> > My application failed deployment with the error on Weld but worked on OpenWebBeans > {code} > [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier > at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer > at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) > {code} > After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. > From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

2
1
0 / 0

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-574: ------------------------------------- Description: In CDI specification Section 4.3: When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. This needs to be clarified. In more details: I have an application containing two wars. testDiffBDA.war testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class @Inject CounterProducerConsumerModified2 bean; beans-xml-modified2.jar containing one bean and an empty-ish beans.xml : @Inject@CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml <alternatives> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> </alternatives> My application failed deployment with the error on Weld but worked on OpenWebBeans {code} [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) {code} After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. >From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. was: In CDI specification Section 4.3: When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. This needs to be clarified. In more details: I have an application containing two wars. testDiffBDA.war testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class @Inject CounterProducerConsumerModified2 bean; beans-xml-modified2.jar containing one bean and an empty-ish beans.xml : @Inject@CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml <alternatives> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> </alternatives> My application failed deployment with the error on Weld but worked on OpenWebBeans [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) -- After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. >From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. > Should a disabled @Specialized disable a second bean? > ----------------------------------------------------- > > Key: CDI-574 > URL: https://issues.jboss.org/browse/CDI-574 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI specification Section 4.3: > When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. > The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? > Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. > This needs to be clarified. > In more details: > I have an application containing two wars. > testDiffBDA.war > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class > @Inject CounterProducerConsumerModified2 bean; > beans-xml-modified2.jar > containing one bean and an empty-ish beans.xml : > @Inject@CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > <alternatives> > <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> > </alternatives> > My application failed deployment with the error on Weld but worked on OpenWebBeans > {code} > [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier > at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer > at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) > {code} > After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. > From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-574?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-574: ---------------------------------- bq. From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. Not exactly. From Weld's perspective a *specializing* bean enabled in any bean archive disables any *specialized* bean in the application. Note that specialization is not defined per bean archive... > Should a disabled @Specialized disable a second bean? > ----------------------------------------------------- > > Key: CDI-574 > URL: https://issues.jboss.org/browse/CDI-574 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Inheritance and Specialization > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > > In CDI specification Section 4.3: > When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. > The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? > Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. > This needs to be clarified. > In more details: > I have an application containing two wars. > testDiffBDA.war > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class > @Inject CounterProducerConsumerModified2 bean; > beans-xml-modified2.jar > containing one bean and an empty-ish beans.xml : > @Inject@CounterModifiedQualifier String modifiedProducer; > beans-xml-modified.jar.jar > CounterModifiedQualifier (the interface) > CounterProducerModified (the bean implementing that interface) > AlternativeCounterProducerModified (an alternative specialized bean) > beans.xml > <alternatives> > <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> > </alternatives> > My application failed deployment with the error on Weld but worked on OpenWebBeans > [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier > at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer > at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) > -- > After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. > From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. > My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

Today's meeting agenda

by Antoine Sabot-Durand

Hi guys, In todays meeting, We should discuss CDI-10 & related issues. I also like to discuss metadata builder (CDI-558) and give you some insight regarding CDI light. Antoine

9 years, 1 month

2
1
0 / 0

[JBoss JIRA] (CDI-574) Should a disabled @Specialized disable a second bean?

by Emily Jiang (JIRA)

Emily Jiang created CDI-574: ------------------------------- Summary: Should a disabled @Specialized disable a second bean? Key: CDI-574 URL: https://issues.jboss.org/browse/CDI-574 Project: CDI Specification Issues Issue Type: Clarification Components: Inheritance and Specialization Affects Versions: 1.2.Final Environment: n/a Reporter: Emily Jiang In CDI specification Section 4.3: When an enabled bean, as defined in Section 5.1.2, “Enabled and disabled beans”, specializes a second bean, we can be certain that the second bean is never instantiated or called by the container. Even if the second bean defines a producer or observer method, the method will never be called. The spec says only an enabled bean can specialize a second bean. Can a disabled specialized bean specialize a second bean? Weld asserts a disabled specialized bean specializes a second bean while OWB asserts a disabled specialized bean does not specialize a second bean. This needs to be clarified. In more details: I have an application containing two wars. testDiffBDA.war testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class @Inject CounterProducerConsumerModified2 bean; beans-xml-modified2.jar containing one bean and an empty-ish beans.xml : @Inject@CounterModifiedQualifier String modifiedProducer; beans-xml-modified.jar.jar CounterModifiedQualifier (the interface) CounterProducerModified (the bean implementing that interface) AlternativeCounterProducerModified (an alternative specialized bean) beans.xml <alternatives> <class>com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified</class> </alternatives> My application failed deployment with the error on Weld but worked on OpenWebBeans [ERROR ] CWWKZ0004E: An exception occurred while starting the application testDiffBDA. The exception message was: com.ibm.ws.container.service.state.StateChangeException: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers @CounterModifiedQualifier at injection point [BackedAnnotatedField] @Inject @CounterModifiedQualifier com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer at com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0) -- After further investigation and talking to Martin from Weld, the error was caused due to the fact of AlternativeCounterProducerModified disabling the CounterProducerModified bean but itself is not enabled in the jar of beans-xml-modified2.jar. Therefore, no producer is active to produce a bean with the qualifier CounterModifiedQualifier. >From Weld's perspective, any bean annotated with @Specialized disables a second bean regardless whether itself is active or not. My understanding is that the specialized should only take effect if itself is enabled. Otherwise, we run into the situation of where the specialized bean is not enabled but it disabled another bean. To me, it is wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-573: ---------------------------------------- Summary: Review code of CDI class to switch to ServiceLoader Key: CDI-573 URL: https://issues.jboss.org/browse/CDI-573 Project: CDI Specification Issues Issue Type: Feature Request Components: Concepts Affects Versions: 2.0-EDR1 Reporter: Antoine Sabot-Durand Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method. In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-558: ------------------------------------------ One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution #. Put the class in the spec (I don't like it unless we don't find a better solution) #. Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. #. Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand edited comment on CDI-558 at 11/24/15 3:30 AM: -------------------------------------------------------------------- One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution # Put the class in the spec (I don't like it unless we don't find a better solution) # Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. # Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? was (Author: antoinesabot-durand): One use case would be : in Java SE I want to prepare an AnnotatedType to give it as on of the type to discover during container initialization. That's why it can be useful to have a way to create such an AnnotatedType before the container and BeanManager availability. So the built-in bean is not a good idea IMO. If we agree on that I see several solution #. Put the class in the spec (I don't like it unless we don't find a better solution) #. Use Java service loader like we already do with CDIProvider. The loaded service should be a factory allowing getting an instance for AnnotatedTypeBuilder (yeah a factory of builder). That let us the possibility to add another helpers in it later. #. Same as previous but with a classical implementation lookup in classpath. The difference is that service loader is guarantee to still work with java 9 Any other thoughts ? > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Fix For: 2.0 (discussion) > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2015