[JBoss JIRA] (CDI-248) Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-248?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-248:
-------------------------------------
Fix Version/s: 2.0 (discussion)
(was: TBD)
> Provide means to observe a group of qualified events ("Qualifier Inheritance"?)
> --------------------------------------------------------------------------------
>
> Key: CDI-248
> URL: https://issues.jboss.org/browse/CDI-248
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts, Events
> Reporter: Jens Schumann
> Fix For: 2.0 (discussion)
>
>
> We have been using CDI events for application development quite extensively. For instance we use events to propagate entity lifecycle events (@Created/@Updated/@Deleted Customer customer) or GUI selections (@Selected/@Deselected Customer customer) and implement related business logic in event observers. (e.g. send email for newly created customers, clear cached values on select/deselect/create/update/delete ...).
> This works quite well, however we have noticed that especially our JSF Presentation Tier contains lots of observer methods implementing the same behavior for a group of related CDI events.
> Example:
> {code}
> public class XyzBean {
> public void onCustomerCreate(@Observes @Created Customer customer) { reset();}
> public void onCustomerUpdate(@Observes @Updated Customer customer) { reset();}
> public void onCustomerDelete(@Observes @Deleted Customer customer) { reset();}
>
> }
> {code}
> Looks ugly, doesn't it?
> The above example could be improved if CDI would be able to observe a group of qualified events, e.g. public void onCustomerLifeCycleEvent(@Observes @LifeCycleChange Customer customer) { reset(); } - ignore method and qualifier names for now.
> Since Java does not support annotation inheritance grouping could be achieved using "qualified qualifier annotations":
> {code}
> @Qualifier
> public @interface LifeCycleChange
> @Qualifier
> @LifeCycleChange
> public @interface Created
> @Qualifier
> @LifeCycleChange
> public @interface Updated
> @Qualifier
> @LifeCycleChange
> public @interface Deleted
> @Qualifier
> public @interface SelectionChange
> @Qualifier
> @SelectionChange
> public @interface Selected
> @Qualifier
> @SelectionChange
> public @interface Deselected
> {code}
> WDYT? Side effects? Problems?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 3 months
Workshop doc
by Antoine Sabot-Durand
Hi all,
So I created all the documents in Google Drive for the workshop and all the corresponding Epic tickets in Jira. I still have to link existing tickets to these Epic.
Regarding the docs they’re all accessible in this drive folder : https://drive.google.com/open?id=0B2Jt7n2J0gR9TENtTnVOTC01alE&authuser=0
By default you can only read theses doc, if you want to comment them just ask. To make our life simple if you ask for one doc, we’ll give you comment right to all.
Pete and I have edit right on all doc but will play the game and will avoid to write directly and use “suggestion” mode.
Now it’s time to decide if you want to take the lead on one of these workshop. I’ll start a new thread on the subject.
Regards,
Antoine
10 years, 3 months
[JBoss JIRA] (CDI-224) Support Decoration of no interface beans
by Thomas Andraschko (JIRA)
[ https://issues.jboss.org/browse/CDI-224?page=com.atlassian.jira.plugin.sy... ]
Thomas Andraschko commented on CDI-224:
---------------------------------------
"outcry" :D
We have a big product with many subproducts and customizations for customers.
In our core libs, we have many default view controllers beans and JSF cc's/includes..
For some subproducts, we @Specialize the view controllers or even create seperate includes.
e.g.
core -> ViewAController
subprojectA -> SpecializedViewAController
Thats work fine with @Specialized/@Alternative.
We also have shared libs for each customer.
There we would like to decorate e.g. ViewAController.
As our controller are currently classes, it would be perfect if it would be possible to apply decorators also on classes.
Currently we have to introduce interfaces for our view controllers, which is actually only a workaround for this feature request because we don't gain any other benefit from it.
> 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.3.1#6329)
10 years, 3 months