[JBoss JIRA] (CDI-403) why decorator requires interface
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-403?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-403.
--------------------------------------
Resolution: Duplicate Issue
Duplicate of CDI-224
> why decorator requires interface
> --------------------------------
>
> Key: CDI-403
> URL: https://issues.jboss.org/browse/CDI-403
> Project: CDI Specification Issues
> Issue Type: Feature Request
> …
[View More] Reporter: Mathieu Lachance
> Labels: F2F2016
> Fix For: 2.0 (discussion)
>
>
> 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)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-414:
-------------------------------------
Priority: Minor (was: Major)
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> …
[View More]Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Priority: Minor
> Fix For: 2.1 (Discussion)
>
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
> @EJB
> private Foo self;
> // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-414:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.0 (discussion))
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> …
[View More]Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.1 (Discussion)
>
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
> @EJB
> private Foo self;
> // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-437:
-------------------------------------
Fix Version/s: 2.1 (Discussion)
(was: 2.1)
> The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
> -----------------------------------------------------------------------------------------
>
> Key: CDI-437
> URL: https://issues.…
[View More]jboss.org/browse/CDI-437
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Priority: Minor
> Labels: F2F2016
> Fix For: 2.1 (Discussion)
>
>
> {quote}
> Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation.
> {quote}
> However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class.
> The container can either:
> * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or
> * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering
> The first option seems to be less harmful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months
[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-437:
-------------------------------------
Fix Version/s: 2.1
(was: 2.0 (discussion))
> The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
> -----------------------------------------------------------------------------------------
>
> Key: CDI-437
> URL: https://issues.…
[View More]jboss.org/browse/CDI-437
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Priority: Minor
> Labels: F2F2016
> Fix For: 2.1 (Discussion)
>
>
> {quote}
> Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation.
> {quote}
> However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class.
> The container can either:
> * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or
> * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering
> The first option seems to be less harmful.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
[View Less]
8 years, 6 months