Interceptor bindings from interceptor when using 2.0 interception factory
by arjan tijms
Hi,
Normally a workaround to get the interceptor bindings from within an
Interceptor is to inspect the target and/or the injected intercepted bean.
However, when adding an interceptor via the new CDI 2.0 interception
factory, things become a bit more muddy.
See e.g.
https://github.com/javaee-samples/javaee8-samples/blob/master/cdi/interce...
Weld has the following method to get the bindings from the
InvocationContext:
Set<Annotation> bindings = (Set<Annotation>)
invocationContext.getContextData().get("org.jboss.weld.interceptor.bindings");
But this is obviously non-standard.
Is there a standard way to get the bindings? Perhaps getting hold of the
Bean<T> that represents the current Interceptor?
Kind regards,
Arjan Tijms
7 years, 2 months
[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-713:
-----------------------------------
The {{Provider}} is not the actual type you create proxy from, therefore it doesn't matter if it's proxyable. The rules of proxyability apply to {{Long}} here.
{{Provider//Instance}} is more of a holder, allowing you to delay injection and have greater control over it at runtime. It's not meant as "proxyable wrapper".
> Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-713
> URL: https://issues.jboss.org/browse/CDI-713
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions, Resolution
> Affects Versions: 1.2.Final
> Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final.
> Reporter: Scott Stark
>
> In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers:
> {code:java}
> @Inject
> @Claim(standard = Claims.iat)
> private Provider<Long> providerIAT;
> {code}
> {code:java}
> @Produces
> @Claim(standard = Claims.iat)
> @RequestScoped
> Long getIAT() {
> JsonWebToken jwt = getJWTPrincpal();
> if (jwt == null) {
> System.out.printf("getIAT, null JsonWebToken\n");
> return null;
> }
> System.out.printf("getIAT\n");
> return jwt.getIssuedAtTime();
> }
> {code}
> I ran into the following exception:
> {noformat}
> Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}.
> at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144)
> at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736)
> at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100)
> at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269)
> {noformat}
> The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
by Scott Stark (JIRA)
[ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.sy... ]
Scott Stark commented on CDI-713:
---------------------------------
Ok, so that solution is a possibility I'll explore, but since the injection type has already introduced a proxyable type by using the Provider<Long> type, I'm not understanding why it cannot be matched up to a producer method like that shown previously:
{code:java}
@RequestScoped
@Produces
@Claim(standard = Claims.iat)
Long getIAT() {
return ...;
}
{code}
Why is this fundamentally different than wrapping the issuedAtTime value in an @RequestScoped bean?
> Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-713
> URL: https://issues.jboss.org/browse/CDI-713
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions, Resolution
> Affects Versions: 1.2.Final
> Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final.
> Reporter: Scott Stark
>
> In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers:
> {code:java}
> @Inject
> @Claim(standard = Claims.iat)
> private Provider<Long> providerIAT;
> {code}
> {code:java}
> @Produces
> @Claim(standard = Claims.iat)
> @RequestScoped
> Long getIAT() {
> JsonWebToken jwt = getJWTPrincpal();
> if (jwt == null) {
> System.out.printf("getIAT, null JsonWebToken\n");
> return null;
> }
> System.out.printf("getIAT\n");
> return jwt.getIssuedAtTime();
> }
> {code}
> I ran into the following exception:
> {noformat}
> Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}.
> at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144)
> at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736)
> at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100)
> at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269)
> {noformat}
> The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-713:
----------------------------------
A simple solution for the use case above might be something like:
{code:java}
@RequestScoped
class IssuedAtTimeProducer {
Long issuedAtTime;
@PostConstruct
void init() {
JsonWebToken jwt = getJWTPrincpal();
if (jwt == null) {
issuedAtTime = null;
}
issuedAtTime = jwt.getIssuedAtTime();
}
@Produces
@Claim(standard = Claims.iat)
Long getIAT() {
return issuedAtTime;
}
}
{code}
By the way, a producer method must have scope {{@Dependent}} if it sometimes returns {{null}} (otherwise {{IllegalProductException}} is thrown).
> Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-713
> URL: https://issues.jboss.org/browse/CDI-713
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions, Resolution
> Affects Versions: 1.2.Final
> Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final.
> Reporter: Scott Stark
>
> In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers:
> {code:java}
> @Inject
> @Claim(standard = Claims.iat)
> private Provider<Long> providerIAT;
> {code}
> {code:java}
> @Produces
> @Claim(standard = Claims.iat)
> @RequestScoped
> Long getIAT() {
> JsonWebToken jwt = getJWTPrincpal();
> if (jwt == null) {
> System.out.printf("getIAT, null JsonWebToken\n");
> return null;
> }
> System.out.printf("getIAT\n");
> return jwt.getIssuedAtTime();
> }
> {code}
> I ran into the following exception:
> {noformat}
> Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}.
> at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144)
> at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736)
> at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100)
> at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269)
> {noformat}
> The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-713:
----------------------------------
No, this is not allowed. {{Long getIAT()}} represents a producer method (i.e. bean) and has a normal scope ({{@RequestScope}}). And for an injection point that resolves to a normal scoped bean a client proxy must be injected. For this reason the required bean type must be proxyable. If the given bean type ({{Long}} in this case) cannot be proxied by the container, the container must throw an {{UnproxyableResolutionException}}.
Note that the same rules apply to regular injection and programmatic lookup.
See also [Client proxies|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#client_proxies], [Unproxyable bean types|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#unproxyable] and [The Instance interface|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#dynamic_lookup].
> Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
> ---------------------------------------------------------------------------------------------
>
> Key: CDI-713
> URL: https://issues.jboss.org/browse/CDI-713
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions, Resolution
> Affects Versions: 1.2.Final
> Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final.
> Reporter: Scott Stark
>
> In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers:
> {code:java}
> @Inject
> @Claim(standard = Claims.iat)
> private Provider<Long> providerIAT;
> {code}
> {code:java}
> @Produces
> @Claim(standard = Claims.iat)
> @RequestScoped
> Long getIAT() {
> JsonWebToken jwt = getJWTPrincpal();
> if (jwt == null) {
> System.out.printf("getIAT, null JsonWebToken\n");
> return null;
> }
> System.out.printf("getIAT\n");
> return jwt.getIssuedAtTime();
> }
> {code}
> I ran into the following exception:
> {noformat}
> Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}.
> at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182)
> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144)
> at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736)
> at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100)
> at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269)
> {noformat}
> The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
by Scott Stark (JIRA)
Scott Stark created CDI-713:
-------------------------------
Summary: Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?
Key: CDI-713
URL: https://issues.jboss.org/browse/CDI-713
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions, Resolution
Affects Versions: 1.2.Final
Environment: WildflySwarm 2017.7.0 and Weld 2.4.3.Final.
Reporter: Scott Stark
In looking into the use of javax.inject.Provider wrapped injection point values when dealing with @RequestScoped producers:
{code:java}
@Inject
@Claim(standard = Claims.iat)
private Provider<Long> providerIAT;
{code}
{code:java}
@Produces
@Claim(standard = Claims.iat)
@RequestScoped
Long getIAT() {
JsonWebToken jwt = getJWTPrincpal();
if (jwt == null) {
System.out.printf("getIAT, null JsonWebToken\n");
return null;
}
System.out.printf("getIAT\n");
return jwt.getIssuedAtTime();
}
{code}
I ran into the following exception:
{noformat}
Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException: WELD-001437: Bean type class java.lang.Long is not proxyable because it is final - {2}.
at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:218)
at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:182)
at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:144)
at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:242)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:736)
at org.jboss.weld.bean.builtin.InstanceImpl.getBeanInstance(InstanceImpl.java:189)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:100)
at org.eclipse.microprofile.jwt.test.jaxrs.RolesEndpoint.getInjectedIssuer(RolesEndpoint.java:269)
{noformat}
The spec is not really clear on why this should happen as the javax.inject.Provider is a proxy for the underlying type. It seems to me that this should be allowed, and that the exception I'm seeing from Weld-2.4.3.Final is a bug, but I wanted to get a clarification on why this might be disallowed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-711) BeanConfigurator cannot be used to define alternative beans enabled for an application
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-711?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny edited comment on CDI-711 at 8/17/17 4:48 AM:
------------------------------------------------------------
Looks like a valid use case we missed.
-Just thinking whether there wasn't some kind of a problem with defining an enabled alternative this late in the bootstrap process?-
EDIT: Shouldn't cause any troubles as it is really just a twist on a custom bean with {{@Prioritized}}.
Also, how about adding another method which would allow you to declare the bean as alternative while selecting it at the same time - {{alternativeWithPriority(int priority)}}?
was (Author: manovotn):
Looks like a valid use case we missed.
Just thinking whether there wasn't some kind of a problem with defining an enabled alternative this late in the bootstrap process?
> BeanConfigurator cannot be used to define alternative beans enabled for an application
> ---------------------------------------------------------------------------------------
>
> Key: CDI-711
> URL: https://issues.jboss.org/browse/CDI-711
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 2.0 .Final
> Reporter: Martin Kouba
> Fix For: 2.1 (Discussion)
>
>
> Custom bean implementations may implement {{Prioritized}} interface. There should be probably a {{BeanConfigurator.priority(int priority)}} method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-708) Serialization problems in section "1.3.1. JSF example".
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-708?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-708:
--------------------------------------
Actually #2, I think I was wrong when it comes to the {{EntityManager}}. The CDI spec defines this guy as a "passivate capable dependency" as long as he was looked up through a CDI producer field.
More details: https://stackoverflow.com/a/45681747
> Serialization problems in section "1.3.1. JSF example".
> -------------------------------------------------------
>
> Key: CDI-708
> URL: https://issues.jboss.org/browse/CDI-708
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 2.0 .Final
> Reporter: Martin Andersson
>
> Section "1.3.1. JSF example" provide an example of a class {{Login}}, that saves in its state an {{EntityManager}} reference and two {{Parameter}} references.
> The JPA specification does not say that a {{Parameter}} instance is serializable.
> This is also true for the {{EntityManager}} reference which is {{@Dependent}} (see section "1.3.3. Java EE component environment example"). JPA does not specify that the {{EntityManager}} is serializable and the EJB specification only specifies serialization semantics for passivation-enabled {{@Stateful}} EJB:s (which encourages the bean provider to not mark an {{EntityManager}} reference as transient, see EJB §4.2.1).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-710:
----------------------------------------
[~manovotn] didn't want to hurt anyone but literally was impossible to use in any app or PoC I did based on CDI 2.0 and can't think to real use cases - but demos - where dropping this API would hurt.
About OWB and ForkJoinPool.commonPool: the only reason it is used is to not create a dedicated pool by default (in standalone and EE) and try to just reuse what is here for low async usage (but true it assumes this pool will be used). In Servlet/EE case you add the fact the config would be highly vendor specific and not controllable JVM wide then commonPool was not a that bad choice for the default - at least as bad as a custom one.
> Require default event ExecutorService to be managed on Java EE
> --------------------------------------------------------------
>
> Key: CDI-710
> URL: https://issues.jboss.org/browse/CDI-710
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Guillermo González de Agüero
>
> When running on a Java EE environment, CDI should use a managed executor service by default for asynchronous operations.
> This is already required by the JAX-RS 2.1 spec (http://download.oracle.com/otndocs/jcp/jaxrs-2_1-pfd-spec/index.html), section 5.8:
> {quote}In an environment that supports the Concurrency Utilities for Java EE [13], such as the Java EE Full Profile, implementations MUST use ManagedExecutorService and ManagedScheduledExecutorService, respectively. The reader is referred to the Javadoc of ClientBuilder for more information about executor services.{quote}
> Containers will presumably offer monitoring features and thread pool configuration options for managed executor services.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (CDI-710) Require default event ExecutorService to be managed on Java EE
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-710?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-710:
-----------------------------------
[~meetoblivion] I agree that {{ForkJoinPool.commonPool()}} is a weird choice for EE environment. But that's not really a reason for enforcing a default one, is it? Leaving it up to integrator works just as well plus it can be tweaked and optimized.
I wonder if OWB default choice isn't more like an "absolutely last resort" if you fail to specify other executor?
[~rmannibucau] I think this ticket is more EE-oriented and what you describe are options for standalone mode (SE?), right? But then again, in SE, you would be probably just fine with {{ForkJoinPool}} not to mention you still can use your own tweaked executor and use {{NotificationOptions}} to enforce it. I don't really see the big problem there and I think calling the API "abusive" is a bit harsh and misplaced.
> Require default event ExecutorService to be managed on Java EE
> --------------------------------------------------------------
>
> Key: CDI-710
> URL: https://issues.jboss.org/browse/CDI-710
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Guillermo González de Agüero
>
> When running on a Java EE environment, CDI should use a managed executor service by default for asynchronous operations.
> This is already required by the JAX-RS 2.1 spec (http://download.oracle.com/otndocs/jcp/jaxrs-2_1-pfd-spec/index.html), section 5.8:
> {quote}In an environment that supports the Concurrency Utilities for Java EE [13], such as the Java EE Full Profile, implementations MUST use ManagedExecutorService and ManagedScheduledExecutorService, respectively. The reader is referred to the Javadoc of ClientBuilder for more information about executor services.{quote}
> Containers will presumably offer monitoring features and thread pool configuration options for managed executor services.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
