[JBoss JIRA] (CDI-414) Support for "self" injection
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-414:
---------------------------------------
[~antoinesabot-durand] Again, I would take that to the Java EE expert group. It would be strange to have CDI beans private methods intercepted, and not all the other components (EJBs...). That's why I think that this behaviour should be common to all components, therefore, specified in the Interceptor 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)
9 years, 10 months
[JBoss JIRA] (CDI-475) Support type annotation in assignability of parameterized types
by Antonin Stefanutti (JIRA)
Antonin Stefanutti created CDI-475:
--------------------------------------
Summary: Support type annotation in assignability of parameterized types
Key: CDI-475
URL: https://issues.jboss.org/browse/CDI-475
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Resolution
Reporter: Antonin Stefanutti
Since Java 8 provides support for type annotations, the assignability of parameterized types rules could be updated to support that feature that may add value in a number of use cases.
For example, with lifecycle events resolution, instead of writing:
{code}
Set<Annotation> contextNames = new HashSet<>();
void camelContextNames(@Observes ProcessAnnotatedType<? extends CamelContext> pat) {
if (pat.getAnnotatedType().isAnnotationPresent(ContextName.class))
contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class));
}
{code}
One could directly write:
{code}
void camelContextNames(@Observes ProcessAnnotatedType<@ContextName ? extends CamelContext> pat) {
contextNames.add(pat.getAnnotatedType().getAnnotation(ContextName.class));
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand edited comment on CDI-414 at 9/15/14 9:02 AM:
-------------------------------------------------------------------
[~agoncal], The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) :
{quote}
Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container.
{quote}
So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls.
was (Author: antoinesabot-durand):
@agoncal, The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) :
{quote}
Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container.
{quote}
So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls.
> 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)
9 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection
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:
------------------------------------------
@agoncal, The reference is here : http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method. The last sentence is the important part here (I missed it before) :
{quote}
Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container.
{quote}
So the fact that inner calls shouldn't be intercepted or decorated doesn't come from interceptor spec but from CDI spec itself. We could imagine change that : keep this default behaviour and add an option that could activate AOP on inner calls.
> 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)
9 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-414:
-------------------------------
CDI also defines business methods to not include private methods.
> 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)
9 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-414:
---------------------------------------
BTW, nowhere in the Interceptor 1.2 spec we find the word "proxy" or "public vs private method" interception. Interceptor 1.2 does not really specify that only private methods should not be intercepted. On the other hand, the specification uses the term *business method*. No definition of what a *business method* is in the Interceptor spec. But because interceptors come from the EJB world, if we look at the EJB spec, we can read :
{quote}
3.2 - Local, Remote, and Web Service Client Views
The term business method is used to refer to a method of an enterprise bean that is available for client execution. It may be a method exposed by the local or remote business interface, by the no-interface view, by the local component interface, by the remote component interface, or by the web service client view.
{quote}
So, in the EJB 3.2 spec it is clearly said that private method are not intercepted, but it's not clear in Interceptor 1.2
> 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)
9 years, 10 months
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-473:
--------------------------------
There are some downsides to using Initialized, if not done safely. For one, you don't want to do the initialization logic in there unless you're ok with it being done multiple times (since anyone can fire this event). It's better to still put it in PostConstruct, and leave this method as is.
Which begs the question, is there a benefit to having empty methods just to declare observers?
> Standardize eager initialisation of ApplicationScoped bean
> ----------------------------------------------------------
>
> Key: CDI-473
> URL: https://issues.jboss.org/browse/CDI-473
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Antonin Stefanutti
>
> Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
> While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
> {code}
> void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
> for (AnnotatedType<?> type : eagerBeans)
> // Calling toString is necessary to force the initialization of normal-scoped beans
> BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
> }
> {code}
> There should be a concise way to declare that intent which would then be address by the CDI container, for example:
> {code}
> @ApplicationScoped(eager = true}
> class EagerApplicationScopedBean {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (CDI-469) Allow nonbinding producer methods to have scopes
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-469?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-469:
--------------------------------
Sure, suppose I have this qualifier:
{code:java}
@Qualifier
...
public @interface Converter {
@Nonbind String value();
}
{code}
I can define a producer field like so:
{code:java}
@Produces
@ApplicationScoped
@Converter("fooAtoB")
private Function<A,B> aToBConv = new AToBFunction();
{code}
If however these were lazily instantiated, or I had a map or looked up values via DB call, I need to add a producer method. In this case, I want it to be generic and reusable, however the instances that it returns should be proxied, scope aware (e.g. not unique for each invocation, as is the current behaviour).
{code:java}
@Produces
@Converter
// @ApplicationScoped <-- scope is not valid here
public Function<?,?> createOrFindFunction(InjectionPoint ip) {
// work to look up the function
}
{code}
Scope isnt' valid here as the injection point could be different. What I'm proposing is that we lift this restriction, in cases where the qualifiers are the same.
> Allow nonbinding producer methods to have scopes
> ------------------------------------------------
>
> Key: CDI-469
> URL: https://issues.jboss.org/browse/CDI-469
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Contexts
> Affects Versions: 1.2.Final
> Reporter: John Ament
>
> Currently, you cannot have a nonbinding producer method, e.g. one where the annotation is read at runtime, with a scope. This means that repeated injections always happen. It would be better if you could scope the nonbinding producer methods, so that the results were bound, e.g. to a request scope, so that look ups can be done once.
> The current way to avoid this is to use a holder object with the proper scope.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (CDI-255) Support for Implicit Producers
by Antonio Goncalves (JIRA)
[ https://issues.jboss.org/browse/CDI-255?page=com.atlassian.jira.plugin.sy... ]
Antonio Goncalves commented on CDI-255:
---------------------------------------
When you look at all the Java EE 7 specs, you don't find much :
*Bean Validation 1.1* (§ 10.3. Context and Dependency Injection (CDI) integration)
{code}
@Inject ValidatorFactory;
@Inject Validator;
{code}
*JMS 2.0* (§ 12.4.3. Injection syntax)
{code}
@Inject
private JMSContext context;
{code}
So definitely a section on Java EE about implicit producers
BTW, in the Java EE 7 spec there is *only one single* line of code showing {{@Inject}}
> Support for Implicit Producers
> ------------------------------
>
> Key: CDI-255
> URL: https://issues.jboss.org/browse/CDI-255
> Project: CDI Specification Issues
> Issue Type: Tracker
> Affects Versions: 1.0
> Reporter: Pete Muir
>
> An implicit producer could be registered for every unambiguous resource the Java EE container knows about.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (CDI-473) Standardize eager initialisation of ApplicationScoped bean
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-473?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-473:
-------------------------------------
Note that this can currently be done by:
{code:JAVA}
@ApplicationScoped
public class Foo {
void init(@Observes @Initialized(ApplicationScoped.class) Object event) {
// init
}
}
{code}
> Standardize eager initialisation of ApplicationScoped bean
> ----------------------------------------------------------
>
> Key: CDI-473
> URL: https://issues.jboss.org/browse/CDI-473
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: Antonin Stefanutti
>
> Given the proxying strategy documented in the CDI specification, normal scoped beans get initialize when an injected proxy reference is first called.
> While that's perfectly fine in the vast majority of use cases, that proves inconvenient when dealing with {{ApplicationScoped}} beans that capture application singletons which we want to bound to the application lifecycle with a {{postConstruct}} callback. As this callback is only called when a proxy is invoked, it is frequent to see the application developers using a CDI extension to meet that need, e.g.:
> {code}
> void forceInitialization(@Observes AfterDeploymentValidation adv, BeanManager manager) {
> for (AnnotatedType<?> type : eagerBeans)
> // Calling toString is necessary to force the initialization of normal-scoped beans
> BeanManagerHelper.getReferencesByType(manager, type.getBaseType(), AnyLiteral.INSTANCE).toString();
> }
> {code}
> There should be a concise way to declare that intent which would then be address by the CDI container, for example:
> {code}
> @ApplicationScoped(eager = true}
> class EagerApplicationScopedBean {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months