February 2016 - cdi-dev - Jboss List Archives

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

by arjan tijms (JIRA)

[ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.sy... ] arjan tijms commented on CDI-485: --------------------------------- JSF EG has implemented this too: https://github.com/javaserverfaces/mojarra/blob/master/jsf-ri/src/main/ja... +1 > 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 > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-568: ------------------------------------- Fix Version/s: 2.0 (proposed) (was: 2.0-EDR2) > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/mai...] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-568: ------------------------------------- Fix Version/s: 2.0-EDR2 > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0 (proposed) > > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/mai...] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-568) Enhancing Java SE bootstrap API

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-568?page=com.atlassian.jira.plugin.sy... ] Work on CDI-568 started by Antoine Sabot-Durand. ------------------------------------------------ > Enhancing Java SE bootstrap API > ------------------------------- > > Key: CDI-568 > URL: https://issues.jboss.org/browse/CDI-568 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > > As discussed during our Paris Face to Face meeting, we should work on enhancing the SE bootstrap API designed for EDR1. > The current version has the following flaws: > * Use existing classes was a bad idea (of mine). It prevents us to remove bootstrap classes in Java EE and force the impl to manage extra work if a user in EE try to use boostrap API. > * While the parameter map is useful, I find it's not fitting the CDI strong typed philosophy, so it would be better to use it as fallback for implementation specific configuration. > * Don't provide a nice way to programmatically configure the container behavior. > That's why I'd like to update the proposed API and provide a more complete approach. Starting with the new [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/mai...] could be interesting > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

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

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-485?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-485: --------------------------------- +1 > 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 > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-515: ---------------------------------- bq. Like you can use Instance.destroy() to destroy any instance today. No, you can't. See also CDI-519. > Allow to obtain Bean metadata from javax.enterprise.inject.Instance > ------------------------------------------------------------------- > > Key: CDI-515 > URL: https://issues.jboss.org/browse/CDI-515 > Project: CDI Specification Issues > Issue Type: Feature Request > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 2.0 (proposed) > > > Sometimes it might be useful to obtain Bean metadata from the {{javax.enterprise.inject.Instance}} (similarly as 5.5.8. Bean metadata). The method could be named {{getBean()}} and should have similar restrictions like {{get()}} (e.g. throw {{UnsatisfiedResolutionException}} if appropriate). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-580: ---------------------------------------- Yep, good catch. Then we would probably need a marker: {code} @Produces(annotated = Decoration.class) ProducedType p() {...} @Logged @Decorated @IsAdmin public static class Decoration {} {code} to be able to handle bindings with parameters > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-580: ----------------------------------- [~rmannibucau]] @Interceptors on the method already works. But it intercepts the invocation of the producer method itself. Emily is right, we need some wrapping annotation or another idea ;) > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method

by Sven Linstaedt (JIRA)

[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ] Sven Linstaedt commented on CDI-580: ------------------------------------ One still has to make up the difference between interceptors, that are applied to the producer method and interceptors, that are applied to the product (bean instance). As {{javax.interceptor.Interceptors}} on method level is currently specified as intercepting invocations on the given method with the given interceptors at least for EJBs {quote}Only business method interception or timeout method interception may be specified by a method-level Interceptors declaration.{quote} I would suggest not to reuse the same annotation for a different purpose. Introducing either a new annotation type or adding an attribute to {{@Produces}} seems more understandable from my point of view. > Allow interceptors and decorators to be applied to the return value of a producer method > ---------------------------------------------------------------------------------------- > > Key: CDI-580 > URL: https://issues.jboss.org/browse/CDI-580 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 2.0-EDR1 > Reporter: Mark Struberg > > Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods. > if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object. > We should explore ways to allow this somehow. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

CDI-485 Provide literals for built-in annotations

by Martin Kouba

Hi all, I'd like to prepare a pull request for CDI-485 [1] and include this into CDI 2.0. Are there any objections? Thanks, [1] https://issues.jboss.org/browse/CDI-485 -- Martin Kouba Software Engineer Red Hat, Czech Republic

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev February 2016