[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:
----------------------------------
[~stefanutti] [~jharting] Yep, I believe that example should not work and it's clearly defined by the spec (see also [7.2. Container invocations and interception|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method] for the current wording).
{code:java}
public void selfInvocationTimedMethod() {
timedMethod(); // <-- this is not a "business method invocation"
}
{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
>
> 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)
9 years, 8 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-414:
-------------------------------------
Yes, Weld does not intercept self invocations. My comment only said that it would be technically possible to support it without much trouble.
You are quoting an outdated version of the specification. The relevant quotes would be:
{quote}When the application invokes:
• a method of a bean via a contextual reference to the bean, as defined in Section 6.5.3,“Contextual reference for a bean”, or
• a method of a bean via a non-contextual reference to the bean, if the instance was created by the container (e.g. using InjectionTarget.produce() or UnmanagedInstance.produce()), or
• a business method of a session bean via an EJB remote or local reference,
the invocation is treated as a *business method invocation*.
{quote}
{quote}If, and only if, an invocation is a *business method invocation* it passes through method interceptors and decorators{quote}
{quote}Otherwise, the invocation is treated as a normal Java method call and is not intercepted by the container.
{quote}
> 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)
9 years, 8 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti commented on CDI-414:
----------------------------------------
In the [Metrics CDI extension|https://github.com/astefanutti/metrics-cdi], CDI interceptors are used to monitor bean method invocations. In the following use case, I would expect the self-invocation of the annotated method to be intercepted as well:
{code}
import com.codahale.metrics.annotation.Timed;
public class TimedMethodBean {
@Timed(name = "timedMethod")
public void timedMethod() {
}
public void selfInvocationTimedMethod() {
timedMethod();
}
}
{code}
I gave it a try as I knew Weld is using subclassing as proxying technique though it happens that interception of self-invocation bean method isn't working \[1\]. Besides, neither the CDI nor the Java Interceptors specification make that point explicit. The only reference to that question that I've been able to stumble upon is \[2\]:
{quote}
_Method interception_ by interceptors and decorators applies to _business method invocations_ of a simple Web Bean, enterprise Web Bean or EJB bean.
...
Self-invocations of a simple Web Bean are considered to be business method invocations. However, self-invocations of an enterprise Web Bean or EJB session, singleton or message driven bean are not considered to be business method invocations.
{quote}
>From my understanding, valid use cases exist, implementations are capable of supporting it (OWB uses bytecode manipulation \[3\]), yet it has been "disabled" for consistency with EJB which contradicts \[2\]. That'd be valuable to have that cleared explicitly in the upcoming CDI 2.0 specification as Antoine suggested.
\[1\]: https://github.com/astefanutti/metrics-cdi/blob/4625ce1e75b2651935287d1c2...
\[2\]: http://docs.jboss.org/webbeans/spec/PDR/html/interceptors.html
\[3\]: https://blogs.apache.org/owb/entry/news_from_openwebbeans_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.2.6#6264)
9 years, 8 months
Dynamic 'TypeLiteral' with ParameterizedType, such as Guice
by Luc
Hi,
Today I realized about the method
'javax.enterprise.inject.Instance#select(javax.enterprise.util.TypeLiteral,
java.lang.annotation.Annotation...)' [1], which whas there from 1.0 version.
After watching CDI 'TypeLiteral' implementation, came a question to mind to
me:
Could be done the same, but *with dynamic class type building*?
And my first google search bring me to a post where a user told some of the
benefits of Guice [2] injection and dynamic types [3], which was written at
2010, and it covers exactly my actual needs.
After watching more the 'TypeLiteral' from CDI and how it is done with
Guice, I thought that could be cool to have this feature in CDI too. I know
I can do it for my own project (and I will) but I have a few questions:
* Should I open an issue at CDI Jira? Or is more a Weld issue?
* If the issue is open, I'd like to contribute to its development. A part
of the "easy rules" from http://www.cdi-spec.org/contribute/, what more
should I do?
Thanks!!
[1]:
http://docs.jboss.org/cdi/api/1.0-SP4/javax/enterprise/inject/Instance.ht...,
java.lang.annotation.Annotation...)
[2]: https://github.com/google/guice
[3]:
http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-with-guice/
--
Lucas
9 years, 8 months
[JBoss JIRA] (CDI-414) Support for "self" injection
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-414:
-------------------------------------
It is possible if you choose subclassing or bytecode manipulation for interceptors/decorators support. It is not possible if proxies are used to implement interceptors/decorators. Weld uses subclassing.
> 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)
9 years, 8 months
[JBoss JIRA] (CDI-451) Improve producer method signature capability by accepting qualifier annotations
by Mark Paluch (JIRA)
Mark Paluch created CDI-451:
-------------------------------
Summary: Improve producer method signature capability by accepting qualifier annotations
Key: CDI-451
URL: https://issues.jboss.org/browse/CDI-451
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Beans
Reporter: Mark Paluch
Priority: Optional
CDI supports producer methods which accept the InjectionPoint as argument which allows to access all metadata to the injection point. The InjectionPoint approach adds a certain complexity which is not needed when only qualifier metadata has to be processed. I propose to allow annotation types within the producer method signatures. Code example for a use case:
{code}
@HttpParam("username") @Inject String username
{code}
{code}
import javax.enterprise.inject.Produces;
import javax.enterprise.inject.spi.InjectionPoint;
class HttpParams
@Produces
String getParamValue(HttpParam httpParam) {
ServletRequest request = (ServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
return request.getParameter(httpParam.value());
// current support looks like:
// String getParamValue(InjectionPoint ip) {
// return request.getParameter(ip.getAnnotated().getAnnotation(HttpParam.class).value());
}
}
{code}
Producer methods accepting qualifier annotations ensure to have always an annotation instance, this helps to prevent null pointer access since InjectionPoint.getAnnotated().getAnnotation(java.lang.Class<T>) may return null.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
Proposal: Improve producer method signature capability by accepting qualifier annotations
by Mark Paluch
CDI supports producer methods which accept the InjectionPoint as argument which allows to access all metadata to the injection point. The InjectionPoint approach adds a certain complexity which is not needed when only qualifier metadata has to be processed. I propose to allow annotation types within the producer method signatures. Code example for a use case:
{code}
@HttpParam("username") @Inject String username
{code}
{code}
import javax.enterprise.inject.Produces;
import javax.enterprise.inject.spi.InjectionPoint;
class HttpParams
@Produces
String getParamValue(HttpParam httpParam) {
ServletRequest request = (ServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
return request.getParameter(httpParam.value());
// current support looks like:
// String getParamValue(InjectionPoint ip) {
// return request.getParameter(ip.getAnnotated().getAnnotation(HttpParam.class).value());
}
}
{code}
Producer methods accepting qualifier annotations ensure to have always an annotation instance, this helps to prevent null pointer access since InjectionPoint.getAnnotated().getAnnotation(java.lang.Class<T>) may return null.
Best regards, Mark
--
PALUCH.biz
Heckenpfad 14 // 69469 Weinheim
T. 0 62 01/65 04 24-0 // F. 0 62 01/65 04 24-9
mpaluch(a)paluch.biz
http://www.paluch.biz
9 years, 8 months