[
https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy...
]
Ondrej Mihályi commented on CDI-403:
------------------------------------
I think that it is worth to remove the requirement on interface in CDI2.
It should be fairly easy to specify additional scenario, where the decorator can extend
the decorated class => it would inherit all public methods as if all methods would be
exposed by an interface, and would decorate all beans injected by their class instead of
by interface.
Currently, the way to work around this is to declare such decorator using {{@Specialized}}
+ {{@Alternative}} and delegating to methods in predecessor. This is confusing in the
code, as the decorator pattern is implemented using to other patterns. And it is not the
same as delegate to another injected delegate, as multiple decorators cannot be chained:
{code:java}
@Specialized
@Alternative
public class MyBeanDecorator extends MyBean {
@Overrides
public String hello() {
return super.hello() + ", world!"; // decorates by adding ",
world!" after result of hello()
}
}
{code}
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.4.11#64026)