December 2015 - cdi-dev - Jboss List Archives

[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... ] Antoine Sabot-Durand updated CDI-575: ------------------------------------- Fix Version/s: 2.0-EDR2 > 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 > 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-575) Add test for CDI class

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-575: ---------------------------------------- Summary: 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 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-575) Add test for CDI class

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-575?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-575: ---------------------------------------- Assignee: 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: ---------------------------------------- [~emilyj] any new API doesn't solve your issue since the applications are by hypothesis "legacy". > 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: --------------------------------- Option A is easy but it does not help the customers with legacy applications. It is not their fault in the first place. The JDK change is beyond their control. If we want to make CDI popular, we should help the customers who are stuck if they are unable to update their legacy applications. Option D: Support proxy on all java.x or javax... classes. Since the system property does not sell well, how about introduce a method setAllowProxyingOnUnProxyable(boolean allowProxying) on CDI.java? If not set, false is the default. > 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-548) FireAsyncException conflicting with CompletionStage definition

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand closed CDI-548. ------------------------------------ Resolution: Done > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (CDI-548) FireAsyncException conflicting with CompletionStage definition

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-548?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-548: --------------------------------- This could be marked as resolved since FireAsyncException has been removed. > FireAsyncException conflicting with CompletionStage definition > -------------------------------------------------------------- > > Key: CDI-548 > URL: https://issues.jboss.org/browse/CDI-548 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Jozef Hartinger > > CompletionStage documentation says: > {quote} > if a stage's computation terminates abruptly with an (unchecked) exception or error, then all dependent stages requiring its completion complete exceptionally as well, with a {@link CompletionException} holding the exception as its cause. > {quote} > On the other hand, the CDI spec suggests that if an observer notification fails, the CompletionStage fails with FireAsyncException directly (not wrapped within CompletionException). This creates a conflict as the CDI spec uses the CompletionStage API without fully conforming to its contract. -- 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 Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-566?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-566: --------------------------------- https://github.com/cdi-spec/cdi/pull/268 - this is likely sufficient I think. With regarding to lifecycle events it is already mentioned in first paragraph in https://github.com/cdi-spec/cdi/blob/2.0-EDR2/spec/src/main/asciidoc/core... > 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 > > 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 Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-527: ---------------------------------- +1 for A -1 for introducing a system property >From the user point of view - creating a producer for a third-party class is always risky (and it's not only about final methods, consider for example passivation scopes). For now there are two workarounds for JDK's HashMap/ConcurrentHashMap and similar use-cases: # use the Map/ConcurrentMap interface as the bean class field/return type - bean author # inject the Map/ConcurrentMap interface - bean consumer (see also my comment https://issues.jboss.org/browse/CDI-527?focusedCommentId=13120531&page=co...) bq. We need to provide a way for the applications to continue working. Emily, I understand your point. But I don't think it's a good solution to transfer responsibility to CDI. > 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-468) Extend javax.interceptor.InvocationContext

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-468: --------------------------------- Created https://java.net/jira/browse/INTERCEPTORS_SPEC-32 > Extend javax.interceptor.InvocationContext > ------------------------------------------ > > Key: CDI-468 > URL: https://issues.jboss.org/browse/CDI-468 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Arne Limburg > > Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly. > I propose to extend the javax.interceptor.InvocationContext interface with a method > public Annotation getInterceptorBinding() or > public <A extends Annotation> A getInterceptorBinding(Class<A> type) > The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation. -- 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