October 2017 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-712) Clarify whether is should be possible to "override" built-in Instance/Provider

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-712?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-712: ------------------------------------------ This should be clarified for all built-in bean that container must provide in the spec > Clarify whether is should be possible to "override" built-in Instance/Provider > ------------------------------------------------------------------------------ > > Key: CDI-712 > URL: https://issues.jboss.org/browse/CDI-712 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.1 (Discussion) > > > In theory, an extension could register an alternative custom bean to override the built-in Instance/Provider bean for injection points such as {{@Inject Provider<String>}}. > It is not forbidden at the moment. The spec only states that there must be a built-in bean eligible for any injection point with Instance/Provider required type and any qualifier. See also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#builtin_instance. > It seems to be a powerful feature. On the other hand, it might be a source of confusion. Take for example this injection point: > {code:java} > @Inject > @MyQualifier > Instance<String> instance; > {code} > The qualifier is now considered when calling {{instance.get()}} and NOT when resolving the injection point. > Note that the spec already allows to decorate built-in beans. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-713) Why can't Provider<?> injection points use non-proxyable types with @RequestScoped providers?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-713?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-713. ------------------------------------ Resolution: Rejected As said, this is expected behaviour from the spec. > 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.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-714) No way to access the underlying bean in a producer when using BeanConfigurator

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-714?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-714: ------------------------------------- Fix Version/s: 2.1 (Discussion) > No way to access the underlying bean in a producer when using BeanConfigurator > ------------------------------------------------------------------------------ > > Key: CDI-714 > URL: https://issues.jboss.org/browse/CDI-714 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: John Ament > Fix For: 2.1 (Discussion) > > > I was reusing an example the Weld guys pointed me at. > {code} > InjectionPoint ip = (InjectionPoint)bm.getInjectableReference(new EmptyInjectionPoint(be...), cc); > {code} > The problem is that I'm using the configurator to create the bean, and the resulting function for the producer doesn't have access to the bean that was created. > {code} > abd.addBean() > .addQualifiers(new ClaimLiteral("", Claims.UNKNOWN)) > .addType(type) > .scope(Dependent.class) > .createWith(ClaimProducer.INSTANCE); > {code} > So because of this, I have no way to get the injection point. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-716) Allow to recognize custom Bean at runtime

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-716?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-716: ------------------------------------- Fix Version/s: 2.1 (Discussion) > Allow to recognize custom Bean at runtime > ----------------------------------------- > > Key: CDI-716 > URL: https://issues.jboss.org/browse/CDI-716 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > Fix For: 2.1 (Discussion) > > > At the moment, they only way to tell custom bean (created via {{BeanConfigurator}} or class implementing {{javax.enterprise.inject.spi.Bean}}) from "standard" one is to have an extension and listen to {{ProcessSyntheticBean}}. This is good enough if it's sufficient to tell the difference at bootstrap time. > However, at runtime, there is no way to do this. > We could add a method to {{javax.enterprise.inject.spi.Bean}} which would allow to tell the difference. The name of the method could be {{isCustom()}} or {{getKind()}}. > Generally, there should be no need to differentiate between custom/standard beans, but when digging deeper, it doesn't hurt to know. Putting this into {{Bean}} interface keeps it deep enough while still giving the information. > One of the use cases for this would be CDI-194, which could be "nicely" implemented (avoiding {{null}} values), if there was a way to recognize custom bean. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-717) Element mistakenly removed from beans_2_0.xsd

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-717?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-717: ------------------------------------- Fix Version/s: 2.1 > Element mistakenly removed from beans_2_0.xsd > --------------------------------------------- > > Key: CDI-717 > URL: https://issues.jboss.org/browse/CDI-717 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 2.0 .Final > Reporter: Matej Novotny > Fix For: 2.1 > > > While creating and editing {{beans_2_0.xsd}} there was one line removed as part of [this PR|https://github.com/cdi-spec/cdi/pull/348]. This line is present in {{beans_1_1.xsd}} -> [see the code|https://github.com/cdi-spec/cdi/blob/master/api/src/main/resources/b...]. > To sum up the meaning of this line, it allows presence of any other non-defined element from _other namespace (than target namespace)_ and further on enforces validation of such element against corresponding XSD. > As a consequence of this change, following {{beans.xml}} is valid with CDI 1.2 ({{beans_1_1.xsd}}) but no longer against CDI 2.0 ({{beans_2_0.xsd}}): > {code} > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:weld="http://jboss.org/schema/weld/beans" > xmlns="http://xmlns.jcp.org/xml/ns/javaee" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee > http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" > bean-discovery-mode="all"> > <weld:scan> > <weld:include name="my.package.*"/> > </weld:scan> > </beans> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-715) Transitive stereotype declarations - clarify conflicting default scopes

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-715?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-715: ----------------------------- Fix Version/s: 2.1 (Discussion) > Transitive stereotype declarations - clarify conflicting default scopes > ----------------------------------------------------------------------- > > Key: CDI-715 > URL: https://issues.jboss.org/browse/CDI-715 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Priority: Minor > Fix For: 2.1 (Discussion) > > > Stereotype declarations are transitive. However, the spec is not clear what happens if a stereotype declares a default scope and also a second stereotype which also declares a default scope. Only _"If a stereotype declares more than one scope, the container automatically detects the problem and treats it as a definition error."_ is defined. > > Weld currently does merge the stereotypes and throws {{DefinitionException}} if NOT all stereotypes specify the same scope _and_ the bean does NOT declare a scope (this makes sense imho). > Note that this is not a problem for {{@Named}}, {{@Alternative}} and -interceptor bindings-. > Any {{@Alternative}} makes a bean an alternative. Any {{@Named}} means the name is defaulted. -All bindings are added to the set-. > UPDATE: Interceptor bindings are probably also affected. The interceptors spec defines _"An interceptor binding declared on a method or constructor replaces an interceptor binding of the same type declared at class level or inherited from a superclass."_ (3.3 Binding an Interceptor to a Component) which implies that multiple interceptor bindings of the same type are not supported. So the spec should probably cover cases where stereotypes declare the interceptor bindings of the same type. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

scope vs scope type vs context

by Todor Boev

I am looking for formal definitions of scope, scope type, context The closest seem to be in http://docs.jboss.org/cdi/spec /2.0/cdi-spec.html#scopes Scope: The scope of a bean determines the lifecycle of its instances, and which instances of the bean are visible to instances of other beans, Scope type: A scope type is represented by an annotation type. Context: Scoped objects, exist in a well-defined lifecycle context: ... Custom scopes are normally defined by portable extensions, which must also provide a context object, as defined in The Context interface, that implements the custom scope. These seem vague. Specifically it seems that the spec prefers to talk about "contextual instances" rather that about a uniform set of objects that represent the current "context". Intuitively to me "scope" relates to "context", as "class" relates to "object". The scope seems like a composite type, consisting of all beans (not bean instances) marked with the same scope annotation. The context is an object cache that collects the bean instances of that scope created during a dependency injection pass. Can someone clarify these terms?

7 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2017