September 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-616: ------------------------------------------ Vote on ML bring this resolution: Do nothing but add clarification in the spec : Injection in transient field is not supported. > Injection point declared as transient is not useful > --------------------------------------------------- > > Key: CDI-616 > URL: https://issues.jboss.org/browse/CDI-616 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 1.2.Final > Environment: n/a > Reporter: Emily Jiang > Priority: Minor > > An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes? > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. > => > The isTransient() method returns true if the injection point is a transient field, and > false otherwise. If the injection point represents a dynamically obtained instance then the > isTransient() method returns true if the Instance injection point is a transient field, and > false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach. > Any other better suggestions? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-599) New lifecycle event to handle deployment/statup errors

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-599?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-599. ------------------------------------ Resolution: Rejected too complex to solve one use case. Feature will be done in CDi-527 > New lifecycle event to handle deployment/statup errors > ------------------------------------------------------ > > Key: CDI-599 > URL: https://issues.jboss.org/browse/CDI-599 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Mark Paluch > > With CDI 1.2 the only way to react to deployment/validation errors is to fail on the container start. Some exceptions could be handled/suppressed such as {{UnproxyableResolutionException}}. This ticket is to discuss a new lifecycle event which carries a deployment/validation error so a SPI developer can handle this problem. An example would be to allow unproxyable types in which case the error is reported, a portable extension tells the event to suppress the problem. This way the problem is handled and does not prevent the container start. > For the concrete example of allowing proxying of classes with non-private final methods the user gets a mechanism to run an application which does not conform fully with the CDI spec rules but at least the user is able to use his application. > An example API could look like: > {code} > /** > * The container fires an event of this type for each deployment validation problem. Unhandled validation problems lead to a > * startup exception. Deployment validations can be handled so the container startup is no longer prevented by handled problems. > */ > public interface ProcessDeploymentValidation { > } > /** > * The container fires an event of this type in case of multiple beans match a certain combination of required type and required > * qualifiers and are eligible for injection. This problem can be handled by resolving a bean using {@link #resolve(Bean)}. > */ > public interface ProcessAmbiguousResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * > * @return the set of matching beans for the InjectionPoint. > */ > Set<Bean<?>> getMatchingBeans(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean<?> bean); > } > /** > * The container fires an event of this type in case no bean matches a certain combination of required type and required > * qualifiers and is eligible for injection. This problem can be handled by providing a bean using {@link #resolve(Bean)}. > */ > public interface ProcessUnsatisfiedResolution extends ProcessDeploymentValidation { > /** > * > * @return the affected InjectionPoint. > */ > InjectionPoint getInjectionPoint(); > /** > * Clarify bean resolution by specifying the bean to inject. > * > * @param bean > */ > void resolve(Bean<?> bean); > } > /** > * The container fires an event of this type in case a contextual reference for a bean with a normal scope and a certain bean > * type cannot be obtained because the bean type cannot be proxied by the container. > */ > public interface ProcessUnproxyableResolution extends ProcessDeploymentValidation { > /** > * The unproxyable bean. > * > * @return > */ > Bean<?> getBean(); > /** > * Suppres this problem and allow bean instances that are partially unproxied. > */ > void allowUnproxyable(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-527: ------------------------------------------ In F2F meeting we decided to add "ignoreFinalMethod" method. Adding support for @WithAnnotations on the ProcessBeanAttributes (CDI-270) will also help to create team specific annotation allow this. > allow proxying of classes with non-private final methods > -------------------------------------------------------- > > Key: CDI-527 > URL: https://issues.jboss.org/browse/CDI-527 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 2.0 (proposed) > > > Currently we explicitly disallow proxying of classes with non-private final methods. > EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it. > We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ] Antoine Sabot-Durand closed CDI-78. ----------------------------------- Resolution: Won't Fix Spec doesn't allow this anymore. And it's way too complicated from user perspective. > Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator > ------------------------------------------------------------------------------------------------------------------------ > > Key: CDI-78 > URL: https://issues.jboss.org/browse/CDI-78 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0 > Reporter: Pete Muir > Assignee: Pete Muir > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-232: ----------------------------- Priority: Minor (was: Major) > Relax requirements for built-in Instance > ---------------------------------------- > > Key: CDI-232 > URL: https://issues.jboss.org/browse/CDI-232 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.1.EDR > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > 5.6.2. The built-in Instance > {quote} > The container must provide a built-in bean with: > * Instance<X> and Provider<X> for every legal bean type X in its set of bean types, > * every qualifier type in its set of qualifier types, > {quote} > This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording. > By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-233) Specify target bean archive for bean added via AfterBeanDiscovery.addBean()

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-233?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-233: ------------------------------------- Priority: Minor (was: Major) > Specify target bean archive for bean added via AfterBeanDiscovery.addBean() > --------------------------------------------------------------------------- > > Key: CDI-233 > URL: https://issues.jboss.org/browse/CDI-233 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Portable Extensions > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016, visibility > Fix For: 2.0 (discussion) > > > This may have impact, provided that alternatives, interceptors or decorators are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-437: ----------------------------- Priority: Minor (was: Major) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Priority: Minor > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ] Martin Kouba updated CDI-437: ----------------------------- Labels: F2F2016 (was: ) > The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly > ----------------------------------------------------------------------------------------- > > Key: CDI-437 > URL: https://issues.jboss.org/browse/CDI-437 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > {quote} > Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation. > {quote} > However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class. > The container can either: > * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or > * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering > The first option seems to be less harmful. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-623) Specify what happens when calling addObserverMethod or addBean alone

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-623?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-623: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0 (discussion)) > Specify what happens when calling addObserverMethod or addBean alone > -------------------------------------------------------------------- > > Key: CDI-623 > URL: https://issues.jboss.org/browse/CDI-623 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: John Ament > Labels: F2F2016 > Fix For: 2.0 (proposed) > > > AfterBeanDiscovery exposes methods addObserverMethod and addBean. Both essentially leave dangling configurations that are not usable. > I'd like for this ticket to clarify what happens in those dangling cases, or in cases where a configuration is completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (CDI-624) Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-624?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-624: ------------------------------------- Fix Version/s: 2.0 (discussion) (was: 2.0 (proposed)) > Map SeContainerInitializer.addBeans() and SeContainerInitializer.addAnnotatedTypes() to the application initialization lifecycle > -------------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-624 > URL: https://issues.jboss.org/browse/CDI-624 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Java SE Integration > Affects Versions: 2.0-EDR2 > Reporter: Martin Kouba > Labels: F2F2016 > Fix For: 2.0 (discussion) > > > I believe we should not break the application initialization lifecycle. > So it might be reasonable to state that {{SeContainerInitializer.addAnnotatedTypes()}} maps to {{AfterTypeDiscovery.addAnnotatedType(AnnotatedType<?>, String)}} (note that we would have to sort out missing id) and {{SeContainerInitializer.addBeans()}} maps to {{AfterBeanDiscovery.addBean(Bean<?>)}}. > The other solution would be to remove these methods and introduce the concept of "synthetic container lifecycle event observers" and leverage the configurators API. See also http://weld.cdi-spec.org/news/2016/02/08/weld-se-synth-lifecycle-events/. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2016