[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-420:
------------------------------------------
During CDI F2F we proposed to provide this feature by adding configuration to the {{"all"}} mode with the {{<trim/>}} xml element
{code:xml}
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
bean-discovery-mode="all">
<trim/>
</beans>
{code}
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand reopened CDI-224:
--------------------------------------
Assignee: Antoine Sabot-Durand (was: Pete Muir)
> Support Decoration of no interface beans
> ----------------------------------------
>
> Key: CDI-224
> URL: https://issues.jboss.org/browse/CDI-224
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> According to CDI 1.0 Spec:
> "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
> "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator."
> Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes.
> I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place.
> {code}
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import junit.framework.Assert;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.jboss.shrinkwrap.impl.BeansXml;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(Arquillian.class)
> public class DecoratesClassTestCase {
> @Deployment
> public static WebArchive create() {
> return ShrinkWrap.create(WebArchive.class)
> .addAsWebInfResource(
> new BeansXml().decorators(BusinessDecorator.class), "beans.xml");
> }
>
> @Test
> public void shouldBeAbleToDecorate(BusinessObject business) throws Exception {
> Assert.assertEquals("Decorated Test", business.send("Test"));
> }
>
> @Decorator
> public static abstract class BusinessDecorator extends BusinessObject {
> @Inject @Delegate @Any
> private BusinessObject delegate;
>
> public String send(String msg) {
> return "Decorated " + delegate.send(msg);
> }
> }
>
> public static class BusinessObject {
>
> public String send(String msg) {
> return msg;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-224:
------------------------------------------
To support this, we'd have to introduce a new kind of Decorators by enhancing @Decorator annotation (@Decorator(noView=true)) or a new annotation @NoViewDecorator
> Support Decoration of no interface beans
> ----------------------------------------
>
> Key: CDI-224
> URL: https://issues.jboss.org/browse/CDI-224
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> According to CDI 1.0 Spec:
> "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
> "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator."
> Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes.
> I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place.
> {code}
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import junit.framework.Assert;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.jboss.shrinkwrap.impl.BeansXml;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(Arquillian.class)
> public class DecoratesClassTestCase {
> @Deployment
> public static WebArchive create() {
> return ShrinkWrap.create(WebArchive.class)
> .addAsWebInfResource(
> new BeansXml().decorators(BusinessDecorator.class), "beans.xml");
> }
>
> @Test
> public void shouldBeAbleToDecorate(BusinessObject business) throws Exception {
> Assert.assertEquals("Decorated Test", business.send("Test"));
> }
>
> @Decorator
> public static abstract class BusinessDecorator extends BusinessObject {
> @Inject @Delegate @Any
> private BusinessObject delegate;
>
> public String send(String msg) {
> return "Decorated " + delegate.send(msg);
> }
> }
>
> public static class BusinessObject {
>
> public String send(String msg) {
> return msg;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-224:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> Support Decoration of no interface beans
> ----------------------------------------
>
> Key: CDI-224
> URL: https://issues.jboss.org/browse/CDI-224
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Aslak Knutsen
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> According to CDI 1.0 Spec:
> "Decorators may be associated with any managed bean that is not itself an interceptor or decorator or with any EJB session bean."
> "The set of decorated types of a decorator includes all bean types of the managed bean which are Java interfaces, except for java.io.Serializable. The decorator bean class and its superclasses are not decorated types of the decorator."
> Both CDI and EJB support No interface beans, but for some reason Decorators only work on methods from a Interface. While Interceptors on the other hand work fine with Classes.
> I can see no technical reason to why Decorators should only work on Interfaces since all Proxies etc should already be in place.
> {code}
> import javax.decorator.Decorator;
> import javax.decorator.Delegate;
> import javax.enterprise.inject.Any;
> import javax.inject.Inject;
> import junit.framework.Assert;
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.jboss.shrinkwrap.impl.BeansXml;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(Arquillian.class)
> public class DecoratesClassTestCase {
> @Deployment
> public static WebArchive create() {
> return ShrinkWrap.create(WebArchive.class)
> .addAsWebInfResource(
> new BeansXml().decorators(BusinessDecorator.class), "beans.xml");
> }
>
> @Test
> public void shouldBeAbleToDecorate(BusinessObject business) throws Exception {
> Assert.assertEquals("Decorated Test", business.send("Test"));
> }
>
> @Decorator
> public static abstract class BusinessDecorator extends BusinessObject {
> @Inject @Delegate @Any
> private BusinessObject delegate;
>
> public String send(String msg) {
> return "Decorated " + delegate.send(msg);
> }
> }
>
> public static class BusinessObject {
>
> public String send(String msg) {
> return msg;
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-513) Clarify whether passivating pseudo-scopes are valid
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-513?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-513:
-------------------------------------
Priority: Minor (was: Major)
> Clarify whether passivating pseudo-scopes are valid
> ---------------------------------------------------
>
> Key: CDI-513
> URL: https://issues.jboss.org/browse/CDI-513
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Priority: Minor
>
> On behalf of Jozef I copied this to a CDI ticket... See CDITCK-466
> I personally think it is clear as there is no single word which forbids this and there is a very vocal description about the single flags.
> -----
> AddingPassivatingScopeTest is illegal as addScope for passivating non-normalscopes is perfectly fine.
> There is nothing in the spec which says that a non-normalscope cannot be passivating.
> The practical use case for this is e.g. when bridging over to Spring. Those beans might need to get checked for Serializable BUT spring brings it's own proxies. So we do not need to wrap it into just another normalscoping proxy.
> Actually the test should come in 2 flavours:
> 1.) RomanEmpire being Serializable -> all fine must work
> 2.) RomainEmpire not Serializable -> DefinitionException
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-593:
------------------------------------------
We should mention this interface in the spec, and tell users that a custom bean being an alternative can implement it to be activated globaly.
ObserverMethod section in the spec should be fixed.
> Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc
> ------------------------------------------------------------------------------------
>
> Key: CDI-593
> URL: https://issues.jboss.org/browse/CDI-593
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> * javadoc would definitely deserve some more info
> * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Antoine Sabot-Durand commented on CDI-10:
-----------------------------------------
During F2F meeting 2016, we discussed addition of methods to Beabmanager retrieve the Bean, Contextual instance and original class for a given instance.
Solution should be retrieving the Bean from an instance. Bean provides class, and allows context lookup to retrieve the contextual instance.
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 2.0 (discussion)
>
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-616:
-------------------------------------
Fix Version/s: 2.0 (proposed)
> Injection point declared as transient is not useful
> ---------------------------------------------------
>
> Key: CDI-616
> URL: https://issues.jboss.org/browse/CDI-616
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 (proposed)
>
>
> An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise.
> =>
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
> Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-616 at 9/6/16 9:38 AM:
------------------------------------------------------------------
Vote on ML bring this resolution:
Do nothing but add clarification in the spec : Injection in transient field is not supported.
Section to add this is 5.2.3 and change the title to Legal Injection points.
Mention should state "non portable behaviour will occur"
was (Author: antoinesabot-durand):
Vote on ML bring this resolution:
Do nothing but add clarification in the spec : Injection in transient field is not supported.
> Injection point declared as transient is not useful
> ---------------------------------------------------
>
> Key: CDI-616
> URL: https://issues.jboss.org/browse/CDI-616
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 (proposed)
>
>
> An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise.
> =>
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
> Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
