March 2016 - cdi-dev - Jboss List Archives

Fwd: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI

by Reza Rahman

FYI - more feedback from just another developer that happens to care a great deal about EE. Begin forwarded message: > From: Josh Juneau <juneau001(a)gmail.com> > Date: March 8, 2016 at 7:41:56 AM EST > To: "users(a)javaee-spec.java.net" <users(a)javaee-spec.java.net> > Subject: [javaee-spec users] Re: CompletableFuture Usage in the Platfom vs CDI > Reply-To: users(a)javaee-spec.java.net > > Reza- > > I am in agreement with you. I agree that CompleteableFuture seems to make more sense for asynchronous events than CompletionStage. Given that it is widely acceptable throughout the platform, and the naming aligns more closely with asynchronous activity...I think CompleteableFuture would be a more consistent and standardized choice. > > Thanks > > Josh Juneau > juneau001(a)gmail.com > http://jj-blogger.blogspot.com > https://www.apress.com/index.php/author/author/view/id/1866 > > >> On Mon, Mar 7, 2016 at 6:40 PM, Reza Rahman <reza_rahman(a)lycos.com> wrote: >> The CDI EG is incorporating the concept of CompletableFuture into asynchronous events. Unfortunately for reasons I really don't see as good they are using it's superinterface CompletionStage instead of CompletableFuture. >> >> I think this is a big ease-of-use mistake as CompletableFuture is designed to be the end user high level gateway API while CompletionStage is mostly as SPI intended for framework writers. >> >> Given that the CompletableFuture concept is pretty widely applicable throughout the platform I think there is a need for consistency, oversight and guidance from the platform expert group. Otherwise I fear less than ideal ad-hoc decisions might be made in this case for CDI and possibly others down the line. >> >> What do you think? >

8 years, 9 months

2
5
0 / 0

inheritance of cdi scopes

by Romain Manni-Bucau

Hi guys, spoke on concurrency utilities about the ability to inherit a cdi scope. Idea is to follow request scope more than cdi spec allows. First thought it was a concurrency utilities thing but Reza mentionned can be a CDI one so here it is. Sample: In a servlet i get MyBean which is @RequestScoped, I do some set on it. The i go async (AsyncContext) and trigger a task in another thread. It would be neat - and mandatory in some case by the loose coupling nature of CDI - to get the *same* MyBean *instance* in this thread. With a direct dependency you can easily use message passing pattern - but you loose the loose coupling cause you need to know until which level you unwrap, think t principal case which has 2-3 proxies!. However in practice you have a lot of undirect dependencies, in particular with enterprise concerns (auditing, security...) so you can't really do it easily/naturally. Bonus: One very verbose way is to be able to kind of push/pop an existing context in a thread - wrappers doing it on a Runnable/Consumer/Function/... would be neat. Question: Would CDI handle it in 2.0? Side note: this is really about the fact to reuse a "context context" (its current instances map) in another thread the more transparently possible and match the user vision more than a technical question for now. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com>

8 years, 9 months

7
43
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-525: ---------------------------------- Yep, the {{BeanELResolver}} is also using {{java.beans.Introspector}} and follows JavaBeans spec. On the other hand, the default name of a bean is not a property and we would also break backward compatibility. > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-586) Add spec text for new Literals

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-586: ------------------------------------------ Yep I'm on it > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-586) Add spec text for new Literals

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-586: ---------------------------------------- Assignee: Antoine Sabot-Durand > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-525: ------------------------------------------ [~mkouba] what are the rules used in EL for JSF and JSP? In my memories it was the one defined in Javabeans, but I may be wrong... > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

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

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-500?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-500: ---------------------------------- The impl should probably inject {{null}} and log a warning. > 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 (discussion) > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-525) Default names should maybe follow the inferring rules from the JavaBean spec

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-525?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-525: ---------------------------------- [~antoinesabot-durand] This issue should be probably rejected. > Default names should maybe follow the inferring rules from the JavaBean spec > ---------------------------------------------------------------------------- > > Key: CDI-525 > URL: https://issues.jboss.org/browse/CDI-525 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Martin Kouba > > *3.1.5. Default bean name for a managed bean*: > {quote} > The default name for a managed bean is the unqualified class name of the bean class, after converting the first character to lower case. > {quote} > As a result, the default name for a bean class {{URLMatcher}} should be {{uRLMatcher}}. On the other hand the JavaBean spec is using different rules when inferring property names, *8.8 Capitalization of inferred names*: > {quote} > However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone. > {quote} > I.e. the property name for getter {{getURLMatcher()}} woud be {{URLMatcher}}. > Note that there is no TCK test for this and so implementations may differ (issue is already filed: CDITCK-473). Weld is using {{java.beans.Introspector.decapitalize()}} and so it follows the JavaBean spec even now. I'm not sure about OpenWebBeans. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-586) Add spec text for new Literals

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-586: ---------------------------------- Yes, "5.6.3. Using AnnotationLiteral and TypeLiteral" looks like a suitable section. > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (CDI-586) Add spec text for new Literals

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-586?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-586: ------------------------------------- Fix Version/s: 2.0-EDR2 > Add spec text for new Literals > ------------------------------ > > Key: CDI-586 > URL: https://issues.jboss.org/browse/CDI-586 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > CDI-485 introduced literals in the API. We should add some information about them in the spec as well -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev March 2016