February 2016 - cdi-dev - Jboss List Archives

by Antoine Sabot-Durand

Hi guys, Re-reading materials and all our discussion on CDI-527, I think there's an option we didn't explore Instead of introducing a new annotation, we could loose rules on proxied bean creation for class having final methods. Today if you declare a class requiring a proxy (because of scope or AOP) you'll get an exception, so nobody declares a bean with such a feature since the app wouldn't deploy. It's the same for producer: you won't declare an @ApplicationScoped producer for a type having final method since your app won't deploy. So in today existing code, final method are in non cdi code or in cdi code that doesn't requires proxy (@Dependent without AOP) If we decide to loose the rules in "3.15 Unproxyable bean types" [1] it won't have impact on existing code (unless I missed something), since you can't have proxied bean with final method without deployment error. It would only allow new proxied bean with final method in it. Change should also be made in "7.2. Container invocations and interception" [2] to explicitly exclude final methods from the list of business method. This change could be seen as not backward compatible, but since current code cannot have proxied bean with final class it doesn't change existing behavior but allow new usage. It also allow code with producer for class of the JDK introducing final in their code to continue working seamlessly in CDI 2.0. Finally that prevent us to introduce specific annotation or configuration looking like a hack. In the past we already introduce behavior changes when we changed the list of bean defining annotation in CDI 1.2 or when we loose usage of certain beanManager method in AfterBeanDiscovery event (I see this proposal very like this last example). Wdyt ? Antoine [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#unproxyable [2] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#biz_method

8 years, 11 months

2
1
0 / 0

preparation for todays meeting

by Mark Struberg

Hi folks! I would love to discuss CDI-420 today. This is open since 2 years now and I’ve shipped a pull request already 2 weeks ago. LieGrue, strub

8 years, 11 months

1
0
0 / 0

Full rewrite for CDI 558 / PR 270

by Antoine Sabot-Durand

Hi all, Following discussion during last meeting, I rewrote most of my PR for builders. We now have 2 clean and distinct ways of using them 1) in DSL style (with a Configurator interface without build() method) public void processAT(@Observes ProcessAnnotatedType<?> pat) { pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new AnnotationLiteral<MyInterceptor>() {};); } 2) In classical reusable builder mode (builders extends configurator and only add build() method) public void processAT(@Observes ProcessAnnotatedType<?> pat) { AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder(); atb.read(pat.getAnnotatedType()).addToType(new AnnotationLiteral<MyInterceptor>() {};); pat.setAnnotatedType(atb.build()); } As Configurators don't have build() method there's no risk that users mix them with standard builders. For clarity sake, builders are no more available in lifecycle event but in Builders class for consistency. I'm quite happy with the result, but I'm sure you'll have comment ;). So thanks for your feedback https://github.com/cdi-spec/cdi/pull/270 Antoine

8 years, 11 months

2
4
0 / 0

Cancelled: CDI weekly meeting

by Antoine Sabot-Durand

8 years, 11 months

1
0
0 / 0

adding generic producers to CDI 2.0?

by Romain Manni-Bucau

Hi guys, could CDI 2 do step forward for generic producers? The need is to produce any type (with a particular qualifier) without the need of an extension: @Produces @MyQualifier Object create(InjectionPoint ip) { ... } This is actually a common pattern (for configuration, or to integrate with 3rd party libs) and today the only hope to do so is to write an extension which is a bit technical and verbose for the result IMO. I guess for compatibility reason we would need to do something like: @Produces @MyQualifier @Generic Object create(InjectionPoint ip) { ... } and say that if there is a unique resolved bean thanks to qualifiers which is annotated @Generic then use this producer. wdyt? 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, 11 months

2
2
0 / 0

[JBoss JIRA] (CDI-485) Provide literals for built-in annotations

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-485: ---------------------------------- A default instance only makes sense for annotations with default values, e.g. for {{@New}} and {{@Typed}}. For {{@Initialized}} it does not make sense. > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/... > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/j... > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java... > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral<Default> implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (CDI-485) Provide literals for built-in annotations

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand commented on CDI-485: ------------------------------------------ And what about {{INSTANCE}} for annotations having members like {{@New}}, {{@Typed}}, {{@Destroyed}} or {{@Initialized}} ? > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/... > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/j... > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java... > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral<Default> implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods

by George Gastaldi

+1

8 years, 11 months

3
4
0 / 0

[JBoss JIRA] (CDI-485) Provide literals for built-in annotations

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-485: ---------------------------------- I'm going to add literals for: * {{javax.enterprise.inject.Any}} * {{javax.enterprise.inject.Default}} * {{javax.enterprise.inject.New}} * {{javax.enterprise.util.Nonbinding}} * {{javax.enterprise.context.Initialized}} * {{javax.enterprise.context.Destroyed}} * {{javax.enterprise.context.RequestScoped}} * {{javax.enterprise.context.SessionScoped}} * {{javax.enterprise.context.ApplicationScoped}} * {{javax.enterprise.context.Dependent}} * {{javax.enterprise.context.ConversationScoped}} * {{javax.enterprise.inject.Alternative}} * {{javax.enterprise.inject.Typed}} * {{javax.inject.Named}} * {{javax.inject.Qualifier}} * {{javax.inject.Singleton}} Any other tips? If possible I will place the literal as a static nested class inside the annotation definition (as Jozef suggested), so that one could use {{Any.Literal.INSTANCE}} or {{Initialized.Literal.of(RequestScoped.class)}}. > Provide literals for built-in annotations > ----------------------------------------- > > Key: CDI-485 > URL: https://issues.jboss.org/browse/CDI-485 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Jozef Hartinger > Assignee: Martin Kouba > > Annotation literals are often useful and therefore many projects implement them themselves. For example: > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/... > https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... > https://github.com/forge/furnace-cdi/blob/master/impl/src/main/java/org/j... > https://github.com/astefanutti/metrics-cdi/blob/master/impl/src/main/java... > to name a few. > It would be nice to provide these within the CDI API, e.g: > {code:JAVA} > @Target( { TYPE, METHOD, PARAMETER, FIELD }) > @Retention(RUNTIME) > @Documented > @Qualifier > public @interface Default { > @SuppressWarnings("all") > final class Literal extends AnnotationLiteral<Default> implements Default { > private Literal() { > } > } > final Default INSTANCE = new Literal(); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 11 months

1
0
0 / 0

Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods

by Florent Benoit

+1 : I'm favorable for adding this feature in the spec On Tue, Feb 9, 2016 at 5:36 PM, Antoine Sabot-Durand < antoine(a)sabot-durand.net> wrote: > Hi all, > > There have been a lot of discussion around CDI-527 in the last weeks: > https://issues.jboss.org/browse/CDI-527 > > Mark proposed a PR: > https://github.com/cdi-spec/cdi/pull/271 > > But we don't agree on adding this feature to the spec. > This vote is to decide if we should add this feature at the spec level > now, or not. > Should we vote this feature down, that won't mean it will be completely > dropped: it could be implemented as non portable feature in both Spec or > even be included as experimental feature in the spec (in annexes) as > describe in the PR comments > Vote starts now, only vote from EG members are binding (but you can give > your opinion if not part of the EG) and will last 72 hours. > > You vote with the following values: > +1 : I'm favorable for adding this feature in the spec > -1 : I'm against adding this feature in the spec > 0 : I don't care > > Thank you for your attention and your vote. > > Antoine Sabot-Durand > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the > code under the Apache License, Version 2 ( > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other > intellectual property rights inherent in such information. >

8 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2016