[JBoss JIRA] (CDI-414) Support for "self" injection
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-414:
-----------------------------------
Had an offline conversation with Martin. The real reason is not the interceptor but the check in Weld that you cannot inject itself in @Dependent scoped beans. Of course a SLSB is not _really_ @Dependent but this was only a hack to describe that CDI should not apply own proxies. But this triggers the aforementioned check in Weld. Which is not wrong from a plain spec perspective - but it is not really helpful.
In OWB we do not check for cyclic injection at all as there are just too many scenarios where it can happen.E.g A->B->A, A->B->C->A,... + all combinations with @PostConstruct, @Inject methods, @Inject constructors, etc. You will get a stackoverflow anyway if you do this. Not as nice a msg as in Weld, but we don't restrict constellations which are perfectly valid that way ;)
Please also note that the same might happen if you use @Scope scopes in Weld. Even if those non-299 scopes bring their own proxies, correct Martin?
> 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.3.1#6329)
10 years
[JBoss JIRA] (CDI-414) Support for "self" injection
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-414:
----------------------------------
{quote}
In the end, it must not make any difference whether you use @Inject or @EJB to inject the SLSB into itself.
{quote}
Then we must standardize this somehow...
> 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.3.1#6329)
10 years
[JBoss JIRA] (CDI-414) Support for "self" injection
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-414:
-----------------------------------
The usage of '@Dependent' on our side was just a way to say 'EJB should take care about all the proxies and interceptors'.
In the end, it must not make any difference whether you use @Inject or @EJB to inject the SLSB into itself. If it does, then this is a container bug.
> 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.3.1#6329)
10 years
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-4:
---------------------------------
[~lightguard]] same unspecified behaviour as we have today for ALL observers ;)
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (CDI-4) Need a way to provide ordering for Event observers
by Jason Porter (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Jason Porter commented on CDI-4:
--------------------------------
If we have something at the same priority level, is it just unspecified behavior?
> Need a way to provide ordering for Event observers
> --------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Assignee: Pete Muir
> Fix For: 2.0 (discussion)
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (CDI-414) Support for "self" injection
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-414:
----------------------------------
Mark, I don't question the existence of EJB proxies. My point is that the CDI spec does not force the implementation to support the self-injection example as given in the description of this issue (because of SLSBs are @Dependent).
> 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.3.1#6329)
10 years
[JBoss JIRA] (CDI-414) Support for "self" injection
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-414:
-----------------------------------
Martin, the CDI EG has discussed this in length. If you check our discussion in CDI-243 and CDI-278 you will remember that the reason for this wording was exactly _because_ the EJB must already provide their own proxies and the CDI Container does _not_ add _another_ proxy to it. But of course the original EJB proxy *must be there* as required by the spec.
> 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.3.1#6329)
10 years
[JBoss JIRA] (CDI-414) Support for "self" injection
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-414:
----------------------------------
{quote}
Of course @Inject in @Stateless beans should work the same way as @EJB. It actually should really make no difference if you resolve the EJB via @Inject, @EJB or manually from JNDI. If this doesn't work it is a bug imo.
{quote}
Well, this is not required by the spec. A SLSB must belong to the @Dependent pseudo-scope and the container is not required to support circular dependencies where every bean in the chain has a pseudo-scope. So there is a difference. In my opinion, SLSBs should belong to a special scope (see also CDI-278).
> 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.3.1#6329)
10 years
Interceptor scopes
by John D. Ament
Hi,
Let's suppose I'm deploying a WAR file w/ multiple JAR files. The WAR has
a beans.xml w/ interceptors defined in it. The JARs each have beans.xml,
but no interceptors defined within them.
Should the interceptors in the WAR apply to all of the JAR files?
Thanks,
John
10 years
[JBoss JIRA] (CDI-453) Support for external interceptor configuration
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-453?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-453:
----------------------------------------
+1
snice most of servers consider it as global by default we should consider having it as default and allowing only to restrict an interceptor to a bean archive (in <interceptor /> we can add an attribute restricted=true|false)
> Support for external interceptor configuration
> ----------------------------------------------
>
> Key: CDI-453
> URL: https://issues.jboss.org/browse/CDI-453
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Interceptors, Java EE integration, Java SE Integration
> Affects Versions: 1.2.Final
> Reporter: John Ament
> Priority: Minor
>
> Currently, there is no way to flag that an interceptor should be globally enabled/disabled within an archive/application.
> Say that I have a common JAR with some interceptor annotations on various beans within it. This JAR has two targetted runtimes, one in a servlet/app server runtime where in one interceptor should be enabled and another disabled. This same JAR is also used within a standalone (SE) batch program where the first interceptor is off and the second is on.
> In this case, I need a way to specify that an interceptor is on, without changing the deployed bean archive. I can currently alleviate this through maven shading, but would prefer not to since it tightly couples the archive to the way consumers use it.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
