January 2016 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?

by Mark Struberg (JIRA)

Mark Struberg created CDI-579: --------------------------------- Summary: Extension disqualifies a jar as 'implicit bean archive'? Key: CDI-579 URL: https://issues.jboss.org/browse/CDI-579 Project: CDI Specification Issues Issue Type: Bug Reporter: Mark Struberg Priority: Minor The bean-discovery-wording is a bit odd. This has been in since CDI-1.1 {code} An archive which: • contains a beans.xml file with the bean-discovery-mode of none, or, • contains an extension and no beans.xml file is not a bean archive. is not a bean archive. {code} That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording? Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below. I'm pretty sure in OWB we will pick those beans up. How does Weld behave? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-578?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-578: ----------------------------------- added error handling for rollback and illegal state. The only technical thing which is missing is SystemException. But this indicates that there is some really low-level setup or container problem. Thus I think we should leave this out of the spec and the containers should just blow up with the Exception. > define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback > ---------------------------------------------------------------------------------------------------------------------- > > Key: CDI-578 > URL: https://issues.jboss.org/browse/CDI-578 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final > Reporter: Mark Struberg > > The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111 > If you have an observer > {code} > public void clearCacheAfterTx((a)Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...} > {code} > and you fire the event > {code} > clearCacheEvent.fire(new ClearCacheEvent()); > {code} > In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server. > The problem is that you cannot enlisten a Synchronisation at the tx anymore. > I think we should define/clarify how it should behave in the various phases. > E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine. > At the end we need a matrix of the the event phases + possible Exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback

by Mark Struberg (JIRA)

Mark Struberg created CDI-578: --------------------------------- Summary: define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback Key: CDI-578 URL: https://issues.jboss.org/browse/CDI-578 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 1.2.Final Reporter: Mark Struberg The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111 If you have an observer {code} public void clearCacheAfterTx((a)Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...} {code} and you fire the event {code} clearCacheEvent.fire(new ClearCacheEvent()); {code} In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server. The problem is that you cannot enlisten a Synchronisation at the tx anymore. I think we should define/clarify how it should behave in the various phases. E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine. At the end we need a matrix of the the event phases + possible Exceptions -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-577) Non-Dependent scope specified on Decorator

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-577?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-577: ------------------------------------- Fix Version/s: 2.0 (proposed) > Non-Dependent scope specified on Decorator > ------------------------------------------ > > Key: CDI-577 > URL: https://issues.jboss.org/browse/CDI-577 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Decorators > Affects Versions: 1.0, 1.2.Final > Reporter: Emily Jiang > Priority: Minor > Fix For: 2.0 (proposed) > > > In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors. > At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour. > Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec: > If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 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 commented on CDI-568: ------------------------------------------ Starting work based on [Weld SE api|https://github.com/weld/core/blob/master/environments/se/core/src/mai...] > 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, 3 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 reassigned CDI-568: ---------------------------------------- Assignee: 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, 3 months

1
0
0 / 0

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

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-527: ----------------------------------- beans_2_0.xsd added and pull request pushed. > 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)

8 years, 3 months

1
0
0 / 0

pull requests broken?

by Mark Struberg

hi folks! I cannot send a pull-request anymore. Only got pete and ales in the fork upstream network list. The official cdi-spec repo is gone from my list. The sha1 chain is fine though. Got this broken by some tinkering with the official repo or is github broken? LieGrue, strub

8 years, 3 months

3
5
0 / 0

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

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-527: ----------------------------------- first draft https://github.com/struberg/cdi/tree/CDI-527 Github pull requests to the official repo is broken currently. Not sure why. See mail on the list. > 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)

8 years, 3 months

1
0
0 / 0

@WithAnnotations and meta-annotations

by Martin Kouba

Hi all, suppose the following use-case: * a class Foo annotated with a stereotype @Alpha which declares another stereotype @Bravo with meta-annotation @Baz * a PAT observer annotated with @WithAnnotations({ Baz.class }) The question is: should this observer method be called for Foo? In other words, how should we interpret "11.5.6. ProcessAnnotatedType event"? The current spec wording seems ambiguous. Weld currently does not perform the check "recursively", i.e. the observer method will not be called as Weld only considers annotations on the annotated type, on any member/parameter of the annotated type, or meta-annotations of such annotations (i.e. goes one level down). I'm not sure about OWB. Also note that there is no TCK test for this special use-case. Thanks, Martin

8 years, 3 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev January 2016