[cdi-dev] [JBoss JIRA] (CDI-414) Support for "self" injection

[Mark Struberg (JIRA)]

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

Mark Struberg edited comment on CDI-414 at 8/17/14 1:17 PM:
------------------------------------------------------------

folks, this sounds absolutely like a bug in current Weld. 
The spec clearly defines that invocation of 'business methods' must get intercepted. We had this discussion a long time ago...
See 7.2
{quote}
When the application invokes:
• a method of a bean via a contextual reference to the bean, ...
the invocation is treated as a business method invocation.
{quote}

And this also used to work in older Weld versions. Self injection is a classic pattern which is heavily used in the industry. E.g. if you have a CDI bean which usually returns values from a cache and only on a cache miss it invokes a @Transactional method to fill the cache. If you now tell me that Weld just ignores this @Transactional interceptor then this is *really* bad news. Again, this used to work in older Weld versions...

There is absolutely nothing which we need to change in the spec as this IS already specified.

*Edit:*
To make this clear what I' refering to:
* calling a method on a self-injected bean (like in the example from Arjan) _must_ trigger the interceptor. If this doesn't work in Weld, then this is clearly a bug
* calling just another method from the same class (without invoking it via the self-injected Contextual Reference must _not_ trigger the interceptor. This was intended that way.




was (Author: struberg):
folks, this sounds absolutely like a bug in current Weld. 
The spec clearly defines that invocation of 'business methods' must get intercepted. We had this discussion a long time ago...
See 7.2
{quote}
When the application invokes:
• a method of a bean via a contextual reference to the bean, ...
the invocation is treated as a business method invocation.
{quote}

And this also used to work in older Weld versions. Self injection is a classic pattern which is heavily used in the industry. E.g. if you have a CDI bean which usually returns values from a cache and only on a cache miss it invokes a @Transactional method to fill the cache. If you now tell me that Weld just ignores this @Transactional interceptor then this is *really* bad news. Again, this used to work in older Weld versions...

There is absolutely nothing which we need to change in the spec as this IS already specified.

> Support for "self" injection
> ----------------------------
>
>                 Key: CDI-414
>                 URL: https://issues.jboss.org/browse/CDI-414
>             Project: CDI Specification Issues
>          Issue Type: Bug
>          Components: Resolution
>            Reporter: arjan tijms
>
> 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.2.6#6264)