[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
other candidates have been
{code}
<trim-beans/>
<require-bean-defining-anntation/>
<optimize/>
<trim-bean-set/>
{code}
trim just stuck out the most as it's always in conjunction with <beans><trim/></beans>
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-224:
---------------------------------------
[~antoinesabot-durand] That does make life more difficult, but would it really hurt if the Decorator would also be applied in case of "helper class extension". Since those are highly unlikely to be injected?
[~thenovot] Yes, however I don't see how the user error risk outways the benefit, it would also be true if a different annotation would be introduced or adding a new element to @Decorator.
Alternatively, the type could be inferred from the @Delegate injection in case of extension.
Another option which pops to mind, not my favorite, is declaring the to be decorated type in the annotation @Decorator(MyRealBean.class). This could then override the interface type inference and be mandatory for extension.
> 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
> Labels: F2F2016
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-420:
--------------------------------
Why not {{<turn-off-beans-if-they-dont-have-bean-defining-annotations />}} (I'm kidding)? It needs a good term. I like the idea, but the naming needs to be better for it to be usable I think.
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-224:
-----------------------------------
[~sknitelius] another food for thoughts - up until now, the delegate was an interface, therefore it only gave you access to methods.
Having a delegate as a class will allow user to access fields which may lead to further user errors (as they are null mostly - you are on a proxy object).
> 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
> Labels: F2F2016
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
Our first draft was
{quote}
<veto-beans-if-no-bean-defining-annotation-present/>
{quote}
But we all agreed, that it would be a tad too much.
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-420:
--------------------------------
{{<trim />}} sounds cool, but doesn't seem to describe what the behavior is.
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-471) Support repeating qualifiers in typesafe resolution mechanism
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-471?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-471:
--------------------------------
Ok, but is the support intended to be inclusive in nature? So to inject this I need both qualifiers present on my injection point, or either?
> Support repeating qualifiers in typesafe resolution mechanism
> -------------------------------------------------------------
>
> Key: CDI-471
> URL: https://issues.jboss.org/browse/CDI-471
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Reporter: Antonin Stefanutti
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> As Java 8 provides improved support for [repeating annotations|http://docs.oracle.com/javase/tutorial/java/annotations/repea...], it would be valuable to percolate that support into the CDI typesafe resolution mechanism.
> For example, one could write:
> {code}
> @Qualifier
> @Repeatable(ContextNames.class)
> public interface @ContextName {
> String value;
> }
> public @interface ContextNames {
> ContextName[] value();
> }
> {code}
> And then:
> {code}
> @ContextName("ctx1")
> class CamelContext1 {
> }
> @ContextName("ctx2")
> class CamelContext2 {
> }
> @Uri("")
> @Produces
> @ContextName("ctx1")
> @ContextName("ctx2")
> static ProducerTemplate producerTemplate(InjectionPoint ip, @Any Instance<CamelContext> instance) {
> }
> {code}
> That enables to use annotations both as a CDI qualifiers and a metadata providers while still be relying on standard typesafe resolution mechanism during the deployment phase to detect unsatisfied or ambiguous dependencies.
> Support of the annotation container / list for backward compatibility could be provided as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 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:
------------------------------------------
We thought about this [~sknitelius], but we may have existing decorator extending class providing them helpers methods, so it won't work.
> 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
> Labels: F2F2016
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-224:
---------------------------------------
I am not so keen on adding another annotation or defining an element on Decorator.
Wouldn't it be sufficient to define something along the lines:
{quote}
If a decorator extends a bean, the decorator's type is inferred from the parent.
{quote}
I don't see how this would cause backwards-compatibility issues, since the behavior of interface based decorators remains unchanged.
> 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
> Labels: F2F2016
> 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)
9 years, 3 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-527 at 9/7/16 6:35 AM:
------------------------------------------------------------------
In F2F meeting we decided to add "ignoreFinalMethod" method to {{ProcessBeanAttribute}}.
Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this.
was (Author: antoinesabot-durand):
In F2F meeting we decided to add "ignoreFinalMethod" method.
Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this.
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months