December 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ] Work on CDI-558 started by Antoine Sabot-Durand. ------------------------------------------------ > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-558: ---------------------------------------- Assignee: Antoine Sabot-Durand > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-558) Standardize the Meta-Data builders API (BeanBuilder, etc...)

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-558?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-558: ------------------------------------- Fix Version/s: 2.0-EDR2 (was: 2.0 (discussion)) > Standardize the Meta-Data builders API (BeanBuilder, etc...) > ------------------------------------------------------------ > > Key: CDI-558 > URL: https://issues.jboss.org/browse/CDI-558 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > The RI includes an experimental BeanBuilder API (see also http://weld.cdi-spec.org/news/2015/02/25/weld-300Alpha5/#_bean_builder_api for more information). The API is similar to the [API provided by DeltaSpike|http://deltaspike.apache.org/javadoc/1.2.1/org/apache/deltaspi...] but also includes some improvements (e.g. Java 8 lambdas may be used to simplify the process of registration). > * BeanBuilder Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * ExperimentalAfterBeanDiscovery Javadoc: http://docs.jboss.org/weld/javadoc/3.0/weld-api/org/jboss/weld/experiment... > * See also [the test extension for more examples of using this API|https://github.com/weld/core/blob/master/tests-arquillian/src/test/ja...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-10) Add ability to access a bean instance from a proxy

by Libor Kramolis (JIRA)

[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ] Libor Kramolis commented on CDI-10: ----------------------------------- *+1 for use case (1).* I hope it will work transparently. It seams to me strange to check if some application class instance is proxy or not to get Annotation instances written on class I've injected. I know I could write utility method for my code (and hope it correctly detects proxies): {code:java} public static <A extends Annotation> A getAnnotationProxyReady(Class<?> clazz, Class<A> annotationClass) { final A annotation = clazz.getAnnotation(annotationClass); if (annotation == null && (clazz.isSynthetic())) { //OK, this is probably proxy return getAnnotationProxyReady(clazz.getSuperclass(), annotationClass); } else { return annotation; } } {code} and now I can access annotation written on bean: {code:java} @Target({ TYPE, METHOD, FIELD }) @Retention(RUNTIME) @Documented public @interface MyAnnotation { String attr1(); int attr2; } @MyAnnotation(attr1="aaa", attr2=42) public class MyBean { //... } @Inject private MyBean myBean; public void methodA() throws NoSuchMethodException { MyAnnotation myAnn = getAnnotationProxyReady(myBean.getClass(), MyAnnotation.class); //use my bean annotations ... } {code} But I can not expect 3rd party libraries support such approach. 3rd party libraries just works with objects and classes and its annotations. They don't what to care about any proxy objects or different proxy implementations to do their business. Note: It works with Annotations annotated by {{@Inherited}} what is expected. {code:java} @Target({ TYPE, METHOD, FIELD }) @Retention(RUNTIME) @Documented @Inherited public @interface MyAnnotation { String attr1(); int attr2; } {code} So I would like to vote for: The proxy bean contains same annotations as original class. And exactly that class not its super-classes. Note: It is necessary to say that it already works for method annotations, see WELD-1131. So the issue remains just on class itself. > Add ability to access a bean instance from a proxy > -------------------------------------------------- > > Key: CDI-10 > URL: https://issues.jboss.org/browse/CDI-10 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 2.0 (discussion) > > > There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method. > Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required. > This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

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

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-527: --------------------------------- >>I have never had an issue with java.* or javax.* being Unproxyable so far. I know a customer has hit this problem after moving up to Java8. Some customers use third party libraries and they don't have source code, so they cannot easily update the code. We can easily say "go to the open source community....". The reality is that it takes time and the customers' applications are not functioning and they cannot operate their business. Someone somehow has to offer help. I think we can address this problem with some careful design. > 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)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-566) Container lifecycle events and context initialization events are synchronous

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-566?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-566: ------------------------------------- Fix Version/s: 2.0-EDR2 > Container lifecycle events and context initialization events are synchronous > ---------------------------------------------------------------------------- > > Key: CDI-566 > URL: https://issues.jboss.org/browse/CDI-566 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Martin Kouba > Fix For: 2.0-EDR2 > > > I believe this should be more explicit. Also portable extensions should be encouraged to fire sync events when a custom context is initialized, see also 6.7. Context management for built-in scopes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

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

by Jens Schumann (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Jens Schumann commented on CDI-527: ----------------------------------- The only situation where I have been running into this issue was integrating CDI in an existing framework, where the entry point to CDI should be as integrated as possible and therefore required extending a framework class with protected final methods. In other words: If you work with framework X you have to extend base class Y (e.g. a web framework action). To make most out of CDI I would love to have an CDI bean extending Y which failed due to the UnproxyableResolutionException. The biggest difference to what you discussed above is: I have to deal with lots of legacy code that should be migrated to a newer stack (slowly). Moving to CDI and CDI interceptors (\@Transactional) requires to work with 10+ years old code, that uses base classes and protected final methods a lot. I have never had an issue with java.* or javax.* being Unproxyable so far. > 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)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-575) Add test for CDI class

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-575?page=com.atlassian.jira.plugin.sy... ] Work on CDI-575 started by Antoine Sabot-Durand. ------------------------------------------------ > Add test for CDI class > ---------------------- > > Key: CDI-575 > URL: https://issues.jboss.org/browse/CDI-575 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Concepts > Affects Versions: 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR2 > > > The class {{javax.enterprise.inject.spi.CDI}} is the entry point for CDI container, but we don't provide any test for it. > As we plan to change its underlying implementation in CDI-573, it seems important to provide a test to be sure that the new implement behaves the same that the current one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

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

by Romain Manni-Bucau (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Romain Manni-Bucau commented on CDI-527: ---------------------------------------- Think we should stay close to java there and don't abuse of bytecode generation since we can end up in a state were we break java (extending classes and proxying final method is already). Proxying types need a no-op constructor for instance even if protected and this one is far more a real constraint when coding than final methods IMHO so users already know what is the technical impl (and implied constraints) so staying aligned on java keeps things understandable I think. More specifically on the new API: this proxying is not always possible for java.* cause some API are not "exposed enough" so it is a super risky hyposthesis and even if the new API is not used on producer code itself the user would need to flag it anyway so the portability of legacy applications is already not free and suppose you hit this issue, what's the fastest? Modifying your code with a Ctrl+R (replace) or checking the spec and implementation for a feature which is maybe not reliable? > 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)

9 years

1
0
0 / 0

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

by Emily Jiang (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Emily Jiang commented on CDI-527: --------------------------------- Romain, the new API is used by CDI integrators (e.g. application servers) to set whether they would like to support this proxying on nonproxyable classes. Weld/OWB should provide the capability of proxying the unproxyable java. or javax. classes. > 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)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev December 2015