November 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-224) Support Decoration of no interface beans

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on CDI-224: ------------------------------- [~seasoned] The decorating types are automatically inferred from the class declaration. If we extend it to always include parent classes, then suddenly all of the parent types would be decorated in *existing applications* when the CDI upgrade is performed. This is not backwards compatible. You would need some way to enable the decorator in this case (for example, adding interfaces...) > 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 > > 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, 1 month

1
0
0 / 0

[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 would also like to see this. [~pmuir] Can you clarify the problem? If the decorator extends the bean only methods defined in the abstract decorating bean should be considered as decorating methods and none of the inherited. > 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 > > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-564) Async events simplification and clarification

by Mark Paluch (JIRA)

[ https://issues.jboss.org/browse/CDI-564?page=com.atlassian.jira.plugin.sy... ] Mark Paluch commented on CDI-564: --------------------------------- After checking the original async ticket I noticed CDI-499 mentions {{fireAsyncEvent()}} on the {{BeanManager}} API but it seems to be never implemented. CDI-557 reports the same issue, but the resolution was to remove textual references. > Async events simplification and clarification > --------------------------------------------- > > Key: CDI-564 > URL: https://issues.jboss.org/browse/CDI-564 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > Following our F2F meeting, we decided to simplify Asynchronous event: > * {{FireAsync()}} should only triggers async observers > * Exception handling should be done with JDK 8 {{CompletionException}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-557) Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method

by Mark Paluch (JIRA)

[ https://issues.jboss.org/browse/CDI-557?page=com.atlassian.jira.plugin.sy... ] Mark Paluch commented on CDI-557: --------------------------------- CDI-499 mentions {{fireAsyncEvent()}} on the {{BeanManager}} API but it seems to be never implemented. > Chapter "10.4.3. The EventMetadata interface" mentions fireAsyncEvent method > ---------------------------------------------------------------------------- > > Key: CDI-557 > URL: https://issues.jboss.org/browse/CDI-557 > Project: CDI Specification Issues > Issue Type: Bug > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Priority: Minor > > http://docs.jboss.org/cdi/spec/2.0.EDR1/cdi-spec.html#event_metadata > In paragraph for isAsync method there is: > {quote} > isAsync() returns true if the event was fired with fireAsync() or fireAsyncEvent() methods otherwise returns false. > {quote} > AFAIK There is no such method. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-541: ----------------------------------- I can see what you mean now. Previously I thought that it is just about invocation order and that the next observer won't be waiting till the previous (with higher priority) finishes. While this makes sense I feel it doesn't exactly follow the idea of loose coupling which goes hand in hand with async handling. Furthermore the 'fire and forget' approach might suffer from this as you might need to mind existing observers (that is if you don't intend to leave it default). Nevertheless, I can definitely see some use cases with the behavior you described. It certainly may come in handy when we want to allow behavior similar to that of sync observers but within a separate thread. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-569) Add @ObservesAsync where the spec mention @Observes

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-569?page=com.atlassian.jira.plugin.sy... ] Work on CDI-569 started by Antoine Sabot-Durand. ------------------------------------------------ > Add @ObservesAsync where the spec mention @Observes > --------------------------------------------------- > > Key: CDI-569 > URL: https://issues.jboss.org/browse/CDI-569 > Project: CDI Specification Issues > Issue Type: Bug > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > In multiple places, the spec mention {{@Observes}}, mainly to forbid observer declaration in certain element. We should add {{@ObservesAsync}} to all these mentions as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-569) Add @ObservesAsync where the spec mention @Observes

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-569: ---------------------------------------- Summary: Add @ObservesAsync where the spec mention @Observes Key: CDI-569 URL: https://issues.jboss.org/browse/CDI-569 Project: CDI Specification Issues Issue Type: Bug Components: Events Affects Versions: 2.0-EDR1 Reporter: Antoine Sabot-Durand In multiple places, the spec mention {{@Observes}}, mainly to forbid observer declaration in certain element. We should add {{@ObservesAsync}} to all these mentions as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-541: ---------------------------------- bq. But there is not really a way to tell that the async observer has finished its work... It is. Async observers with different priorities will have to be notified serially. An observer finishes its work when the {{notify()}} method completes. > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Priority: Major > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-541) Ordering of async observers (vs sync observers) is not specified

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/CDI-541?page=com.atlassian.jira.plugin.sy... ] Matej Novotny commented on CDI-541: ----------------------------------- If I get this correctly then setting different @Priority to async observers will result in one observer being notified later than the other (as in the example given above). But there is not really a way to tell that the async observer has finished its work hence I cannot rely on its job being finished (the underlaying data being changed for instance) while the other observer is already executing. Now the question I have - could you give me a scenario when I would need to have one observer notified later than the other while still not caring about the data they handle (not relying on when they are done executing)? And I mean a scenario which wouldn't end all the same when using async observers without @Priority. Obviously, there might be some but I just cannot see any atm so feel free to enlighten me :) > Ordering of async observers (vs sync observers) is not specified > ---------------------------------------------------------------- > > Key: CDI-541 > URL: https://issues.jboss.org/browse/CDI-541 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Priority: Major > Fix For: 2.0-EDR2 > > > I think this needs to be specified. E.g. what happens if I fire async event and have more matching sync and async observers? Are all sync observes called first in given order with no regard to async observers priority? > For example: > {{event.fireAsync(new Message());}} > {code} > public class First { > > void observeMessage(@Observes @Priority(2000) Message message){} > } > {code} > {code} > public class Second { > > void observeMessage(@ObservesAsync @Priority(2100) Message message){} > } > {code} > {code} > public class Third { > > void observeMessage(@Observes @Priority(2200) Message message){} > } > {code} > {code} > public class Fourth { > > void observeMessage(@ObservesAsync @Priority(2300) Message message){} > } > {code} > What will be the order in this case? First, Third, Second, Fourth? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-542) "10.2.2. Firing events asynchronously" update/enhancements

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-542?page=com.atlassian.jira.plugin.sy... ] Work on CDI-542 started by Antoine Sabot-Durand. ------------------------------------------------ > "10.2.2. Firing events asynchronously" update/enhancements > ---------------------------------------------------------- > > Key: CDI-542 > URL: https://issues.jboss.org/browse/CDI-542 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 2.0-EDR1 > Reporter: Tomas Remes > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > This chapter (similar as the preceding) defines in general what does it mean to "fire an event" (sync vs async). Let say I am ordinary reader reading the spec from the beginning and I come to this chapter. > First of all I guess I will struggle little bit with the notion of ??resolved synchronous observers?? (vs ??resolved asynchronous observers??) > I think the following important information from "10.3. Observer resolution" could be mentioned earlier or some general description/example could be handy: > {quote} > * The event is fired synchronously and the observer is defined with @Observes. > * The event is fired asynchronously and the observer is defined with @Observes or @ObservesAsync. > {quote} > Second there is following sentence which TBH I have had fairly hard times to understand: > {quote} > If synchronous observer have to be notified, fireAsync returns immediately after the last synchronous observer has returned. Otherwise it returns immediately. > {quote} > ...and is IMO wrong. There should be "observers have to be" or "observer has to be" and it could be bit more explanatory. -- 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