[cdi-dev] [JBoss JIRA] (CDI-403) why decorator requires interface

Thomas Andraschko (JIRA) issues at jboss.org
Fri Oct 17 15:40:35 EDT 2014


    [ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013029#comment-13013029 ] 

Thomas Andraschko edited comment on CDI-403 at 10/17/14 3:40 PM:
-----------------------------------------------------------------

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 (senseless!) 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.

It's really an important issue for product development and it would be great to see it in CDI2/JEE8


was (Author: tandraschko):
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 (senseless!) 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.

> why decorator requires interface
> --------------------------------
>
>                 Key: CDI-403
>                 URL: https://issues.jboss.org/browse/CDI-403
>             Project: CDI Specification Issues
>          Issue Type: Clarification
>            Reporter: Mathieu Lachance
>
> As discussed with Jozef Hartinger on the WELD forum thread (see forum reference and CDI-224),
> would it be possible to revisit why decorator requires an interface ?
> I do not understand the semantic difference between:
> 1. a decorator to be an abstract class which implements an interface, which delegate to the same interface. 
> 2. a decorator to be a concrete class which extends a another class, which delegates to the same class.
> Why 1. should be allowed and why 2. should be disallowed ?
> As stated in CDI-224, if there is no technical reason of disallowing 2., should it be then considerate as a vendor specific feature to support it whether or not ?
> It is kind of sad that only decorators requires an interface while all the others Java EE 6 features do not.
> Thanks,



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)


More information about the cdi-dev mailing list