[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 commented on CDI-414:
------------------------------------------
I relaunch discussion on this ticket since we are on the verge to introduce a new annotation related to "proxy" or "business methods" exception with CDI-527.
This annotation could be designed to support broader proxy related feature than just CDI-527 and could provide a solution to extend proxy generation to self invocation.
Suppose the annotation to be like
{code}
@Target({TYPE})
@Retention(RUNTIME)
@Documented
public @interface AllowProxy {
boolean withFinalMethods() default true;
boolean onSelfInvocations() default false;
}
{code}
{{@AllowProxy}} alone could be used for CDI-527, but this annotation could be used for this ticket.
The code provided by [~struberg] above would become
{code}
@ApplicationScoped
@AllowProxy(selfInvocation=true) //ask the container to create proxy on all invocation
public class CountryService {
private List<Country> cachedCountries;
public List<Counry> getCountries() {
if (cachedCountries == null) {
loadCountries(); // this call would be a business method call thanks to the annotation
}
return cachedCountries;
}
// Transactional aspect will be activated for all calls including from method in the same instance
@Transactional
protected synchronized loadCountries() {
if (countries != null) return;
countries = em…. load all countries form DB
}
}
{code}
As [~jharting] stated multiple times above, it is technically doable thanks to subclassing proxy.
It's not done today because CDI was initially aligned on EJB regarding interception.
Today Interceptor spec is no more part EJB and refers to "business method" concept (without defining it) for interception.
CDI has its own definition of "business method" in http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method, so we could imagine adding definition for business method with this new annotation and stay consistant with interceptor spec.
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.0 (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)
8 years, 10 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:
-------------------------------------
Summary: Support for "self" injection or intercepted self invocation (was: Support for "self" injection)
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.0 (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)
8 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
[~antoinesabot-durand] I thought about 'explicit' as well, but it isn't really describing what happens. See my previous comment.
{quote}
Ad 'scoped' vs 'scanning' vs whatever.
I thought pretty long about it. My first take was 'explicit'. Because you have to explicitly define the classes you like to get picked up. Otoh this term doesn't define what you need to define. For example: just an @Inject somewhere would be nuts as the detection would be pretty expensive.
And this was the point which did lead me to 'scoped'. Because that's what you need to do: Define a Scope OR an annotation which leads to a defined default scope (decorator, interceptor or stereotype). Those are very easy and fast to find and have very clear rules imo.
{quote}
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius edited comment on CDI-507 at 2/17/16 3:16 PM:
----------------------------------------------------------------
Maybe it would help if it was explecitly mentioned.
Since it is only treated implicitly via @Scoped scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped.
was (Author: sknitelius):
Maybe it would help if it was explecitly mentioned.
Since it is only treated implicitly via {code}@Scoped{code} scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped.
> CDI support for Singleton Pseudo Scope
> --------------------------------------
>
> Key: CDI-507
> URL: https://issues.jboss.org/browse/CDI-507
> Project: CDI Specification Issues
> Issue Type: Clarification
> Environment: --NA-- (documentation)
> Reporter: Abhishek Gupta
>
> Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
> As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
> Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-507:
---------------------------------------
Maybe it would help if it was explecitly mentioned.
Since it is only treated implicitly via {code}@Scoped{code} scopes being treated as pseudo scoped. Which can lead to some odd behavior when using javax.inject.Singleton instead of application scoped.
> CDI support for Singleton Pseudo Scope
> --------------------------------------
>
> Key: CDI-507
> URL: https://issues.jboss.org/browse/CDI-507
> Project: CDI Specification Issues
> Issue Type: Clarification
> Environment: --NA-- (documentation)
> Reporter: Abhishek Gupta
>
> Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
> As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
> Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[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:
-----------------------------------
Rolling a few ideas with Antoine, we thought it might be better to have a code sample about how it looks today.
And then we can figure how it _might_ look in the future
Here is the current solution to start with:
{code}
@ApplicationScoped
public class CountryService {
private List<Country> cachedCountries;
private @Inject CountryService _self;
// this method doesn't need to open any transaction
// so keep it fast without any interceptor and TX handling
public List<Counry> getCountries() {
if (cachedCountries == null) {
_self.loadCountries();
}
return cachedCountries;
}
// but over here we might need a transaction...
@Transactional
protected synchronized loadCountries() {
if (countries != null) return;
countries = em…. load all countries form DB
}
}
{code}
> 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
> Fix For: 2.0 (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)
8 years, 10 months
[JBoss JIRA] (CDI-554) Additional built-in beans do not have a scope defined
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-554?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-554:
-----------------------------
Affects Version/s: 1.2.Final
> Additional built-in beans do not have a scope defined
> -----------------------------------------------------
>
> Key: CDI-554
> URL: https://issues.jboss.org/browse/CDI-554
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Martin Kouba
>
> See section 17.8. Additional built-in beans - a scope is not defined for UserTransaction, Principal, HttpServletRequest, etc. Maybe it's defined somewhere else but I cannot find anything.
> In Weld, Java EE beans are {{@Dependent}}, HttpServletRequest and ServletContext are {{@RequestScoped}} and HttpSession is {{@SessionScoped}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-507) CDI support for Singleton Pseudo Scope
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-507?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-507:
----------------------------------
Well, the CDI spec does not mention the {{javax.inject.Singleton}} scope in the relevant section "1.2.4. Relationship to Dependency Injection for Java":
{quote}
The Dependency Injection for Java specification defines a set of annotations for the declaring injected fields, methods and constructors of a bean. The dependency injection service makes use of these annotations.
{quote}
On the other hand, all CDI implementations should pass JSR 330 TCK (see also [CDI TCK reference guide|https://docs.jboss.org/cdi/tck/reference/latest/en-US/html/introduc...]) and so it is defacto supported.
> CDI support for Singleton Pseudo Scope
> --------------------------------------
>
> Key: CDI-507
> URL: https://issues.jboss.org/browse/CDI-507
> Project: CDI Specification Issues
> Issue Type: Clarification
> Environment: --NA-- (documentation)
> Reporter: Abhishek Gupta
>
> Section 2.4.1 states 5 built-in scope types including the pseudo scope @Dependent.
> As per the Weld documentation, CDI also supports an additional pseudo scope - @javax.inject.Singleton (see here --> http://red.ht/1D3qu97)
> Just wanted to confirm whether the CDI Specification document is missing this information or the content in the Weld documentation is incorrect?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods
by Antoine Sabot-Durand
Hi all,
There have been a lot of discussion around CDI-527 in the last weeks:
https://issues.jboss.org/browse/CDI-527
Mark proposed a PR:
https://github.com/cdi-spec/cdi/pull/271
But we don't agree on adding this feature to the spec.
This vote is to decide if we should add this feature at the spec level now,
or not.
Should we vote this feature down, that won't mean it will be completely
dropped: it could be implemented as non portable feature in both Spec or
even be included as experimental feature in the spec (in annexes) as
describe in the PR comments
Vote starts now, only vote from EG members are binding (but you can give
your opinion if not part of the EG) and will last 72 hours.
You vote with the following values:
+1 : I'm favorable for adding this feature in the spec
-1 : I'm against adding this feature in the spec
0 : I don't care
Thank you for your attention and your vote.
Antoine Sabot-Durand
8 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-420:
------------------------------------------
Could be useful to add this granularity, since we don't configure type discovery but bean discovery.
I would prefer {{defined}} (because they have a bean defining annotation) or {{explicit}} for the name of the new bean discovery mode.
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months