October 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-593) Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-593?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-593: ------------------------------------- Sprint: Sprint 1 > Mention javax.enterprise.inject.spi.Prioritized in spec text and improve its javadoc > ------------------------------------------------------------------------------------ > > Key: CDI-593 > URL: https://issues.jboss.org/browse/CDI-593 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > * javadoc would definitely deserve some more info > * the spec text should mention this interface as well and describe basic use cases (e.g. an interceptor passed to {{AfterBeanDiscovery.addBean()}} and implementing this interface is globally enabled) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-612) ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-612?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-612: ------------------------------------- Sprint: Sprint 1 > ObserverMethodConfigurator.notifyWith() should probably accept a functional interface whose method throws java.lang.Exception > ----------------------------------------------------------------------------------------------------------------------------- > > Key: CDI-612 > URL: https://issues.jboss.org/browse/CDI-612 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The regular observer methods may also throw checked exceptions (wrapped and rethrown as an (unchecked) {{ObserverException}}). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-592: ------------------------------------- Sprint: Sprint 1 > Consider adding ObserverMethod.notify() method which also accepts EventMetadata > ------------------------------------------------------------------------------- > > Key: CDI-592 > URL: https://issues.jboss.org/browse/CDI-592 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > {code:java} > // Make the original method also default so that new impls don't need to implement two methods > default void notify(T event) { > // No-op > } > // The container should always call this method... > default void notify(T event, EventMetadata metadata) { > notify(event); > } > {code} > This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-500) Clarify @Intercepted Bean metadata injection for EE components

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-500: ------------------------------------- Sprint: Sprint 1 > Clarify @Intercepted Bean metadata injection for EE components > -------------------------------------------------------------- > > Key: CDI-500 > URL: https://issues.jboss.org/browse/CDI-500 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Interceptors > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > It's not clear what should happen when an interceptor with {{@Intercepted Bean}} metadata is associated with an EE component. > See the CDI spec, "5.5.8. Bean metadata": > {quote} > Additionally, the container must provide beans allowing interceptors and decorators to obtain information about the beans they intercept and decorate: > * a bean with scope @Dependent, qualifier @Intercepted and type Bean which can be injected into any interceptor instance, and > * ... > {quote} > However, most EE components must also support the use of CDI interceptors. See also the Java EE 7 spec, "EE.5.2.5 Annotations and Injection": > {quote} > The component classes listed in Table EE.5-1 with support level "Standard" > all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks. In addition, if CDI is enabled—which it is by default—these classes also support CDI injection, as described in Section EE.5.24, "Support for Dependency Injection", and the use of interceptors. > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-546) Constant for default observer priority

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-546?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-546: ------------------------------------- Sprint: Sprint 1 > Constant for default observer priority > -------------------------------------- > > Key: CDI-546 > URL: https://issues.jboss.org/browse/CDI-546 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Jozef Hartinger > Priority: Minor > Fix For: 2.0 .Final > > > Currently we use: > {code:JAVA} > @Override > public default int getPriority() { > return javax.interceptor.Interceptor.Priority.APPLICATION + 500; > }; > {code} > It would be nice to have the value stored as a constant e.g.: > {code:JAVA} > int DEFAULT_PRIORITY=javax.interceptor.Interceptor.Priority.APPLICATION + 500; > {code} > so that other code can reference it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-497: ------------------------------------- Sprint: Sprint 1 > session scope doesn't follow session lifecycle > ---------------------------------------------- > > Key: CDI-497 > URL: https://issues.jboss.org/browse/CDI-497 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Romain Manni-Bucau > Fix For: 2.0 .Final > > > ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case). > Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-498) Revise "6.7.5. The Conversation interface" - dots are not valid in EL name

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-498?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-498: ------------------------------------- Sprint: Sprint 1 > Revise "6.7.5. The Conversation interface" - dots are not valid in EL name > -------------------------------------------------------------------------- > > Key: CDI-498 > URL: https://issues.jboss.org/browse/CDI-498 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Tomas Remes > Fix For: 2.0 .Final > > > Seems that following part contradicts the EL spec: > {quote}The container provides a built-in bean with bean type Conversation , scope @RequestScoped , > and qualifier @Default , named javax.enterprise.context.conversation .{quote} > The EL name "javax.enterprise.context.conversation" is not valid. > Discussion available at http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2015/%23... > and > http://lists.jboss.org/pipermail/cdi-dev/2015-January/thread.html - topic "where is defined javax.enterprise.context.conversation.id?" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-489) NonexistentConversationException thrown at restore view or not?

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-489?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-489: ------------------------------------- Sprint: Sprint 1 > NonexistentConversationException thrown at restore view or not? > --------------------------------------------------------------- > > Key: CDI-489 > URL: https://issues.jboss.org/browse/CDI-489 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Javadoc and API > Affects Versions: 1.2.Final > Reporter: Vsevolod Golovanov > Fix For: 2.0 .Final > > > The 1.0 spec says in 6.7.4: > {quote}If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore > view phase of the JSF lifecycle. The application may handle this exception using the JSF ExceptionHandler.{quote} > 1.1 and 1.2 just say: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and > throw an exception of type javax.enterprise.context.NonexistentConversationException. > {quote} > Yet the javadoc of NonexistentConversationException for both 1.1 and 1.2 says: > {quote} > If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type NonexistentConversationException from the restore view phase of the JSF lifecycle. > {quote} > So is it supposed to be thrown from restore view or not? I assume not. Probably javadoc should be amended. > I'm curious about reasoning behind the change. I tried searching for an explanation but didn't find anything. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-495: ------------------------------------- Sprint: Sprint 1 > What happens if an illegal bean type is found in the set of bean types > ---------------------------------------------------------------------- > > Key: CDI-495 > URL: https://issues.jboss.org/browse/CDI-495 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Fix For: 2.0 .Final > > > The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-490: ------------------------------------- Sprint: Sprint 1 > Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml > ------------------------------------------------------------------------------------------------ > > Key: CDI-490 > URL: https://issues.jboss.org/browse/CDI-490 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators, Interceptors > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Labels: F2F2016 > Fix For: 2.0 .Final > > > Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because: > {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final > list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote} > it matches both parts of the statement. > As for ordering, the following statement defines invocation order: > {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote} > Since InterceptorA is enabled by both @Priority and beans.xml, the following applies: > "Interceptors enabled using @Priority" = \{ InterceptorA \} > "interceptors enabled using beans.xml" = \{ InterceptorA \} > We can perform substitution in the statement and we get: > *\{ InterceptorA \} are called before \{ InterceptorA \}* > which does not seem right. > The specification should explicitly address this scenario. There are several options (some of them are better, some are worse): > 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml > 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence) > 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence) > 4) Forbid an interceptor to be enabled by both @Priority and beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2016