September 2015 - cdi-dev - Jboss List Archives

[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: ---------------------------------- Accepted on F2F. > 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 > 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)

9 years, 3 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 updated CDI-515: ----------------------------- Fix Version/s: 2.0 (proposed) > 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 > 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)

9 years, 3 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 updated CDI-515: ----------------------------- Fix Version/s: (was: 2.0 (discussion)) > 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 > 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)

9 years, 3 months

1
0
0 / 0

Opening CDI F2F meeting to the community

by Antoine Sabot-Durand

Hi all, As a lot of EG members won't make it for our meeting, if you follow this ml are in Paris on Friday and/or Saturday you can join us for our meeting. Send me a private email if you are interested. Antoine

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage

by Martin Kouba (JIRA)

Martin Kouba created CDI-563: -------------------------------- Summary: Event.fireAsync() - clarify the usage of the returned CompletionStage Key: CDI-563 URL: https://issues.jboss.org/browse/CDI-563 Project: CDI Specification Issues Issue Type: Clarification Components: Events Affects Versions: 2.0-EDR1 Reporter: Martin Kouba So far {{CompletionStage}} is only mentioned in "10.5.1. Handling multiple exceptions thrown during an asynchronous event" and the {{Event.fireAsync()}} javadoc is too general. However, the {{CompletionStage}} itself does not define an unambiguous contract for its methods. E.g. what thread is used to execute a given callback? Or what's the _"stage's default asynchronous execution facility"_? I believe this is left on implementors. In Weld 3.0 Alpha we're using {{CompletableFuture}} under the hood, and its more concrete in this area, e.g.: {quote} * Actions supplied for dependent completions of _non-async_ methods may be performed by the thread that completes the current CompletableFuture, or by any other caller of a completion method. {quote} So as a result, if an async delivery is finished before a sync dependent action is registered, the callback is executed in the caller thread: {code:java} event.fireAsync(new Message()).thenAccept((m) -> System.out.println("This might be executed in a caller thread or in a different thread!")); {code} And this might be confusing. Especially from the context propagation point of view. I think the spec should clarify the contract of a returned {{CompletionStage}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.sys... ] Martin Kouba commented on CDI-20: --------------------------------- I'm not so sure it's a good idea to allow any observer to abort processing of an event. This would be another way to kill the original concept of decoupled interactiion. Ordering might be sometimes handy but to allow to abort the processing seems to me a bit too much. For some use cases it might be better to implement a mutable thread-safe event payload with a flag (as mentioned above) and let the observers handle this alone (e.g. the first one marks the payload as handled and others just skip the processing). > @Observes(propagate = false) - stop event propagation after being handled by an observer > ---------------------------------------------------------------------------------------- > > Key: CDI-20 > URL: https://issues.jboss.org/browse/CDI-20 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.0 > Environment: any > Reporter: Walter White > Fix For: 2.0 (discussion) > > > I would like to have the ability to stop event propagation after it is handled by any observer only for certain situations. Is it possible to add a property to the annotation indicating whether the propagation should continue after being handled by the observer? Alternatively, would it be more concise to add a qualifier annotation which specifies the propagation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

No meeting tomorrow

by Antoine Sabot-Durand

Hi Guys, I'll focus on the F2F meeting preparation. So no meeting tomorrow Regards, Antoine

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-547: ---------------------------------- Yep, it would return both ASYNC + SYNC, the same result one would expect for {{fireAsync()}}. That's why the proposed name contains *ForFireAsync*. The third option may also bring confusion - we will always return observer methods for {{fireAsync()}}. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-547: --------------------------------- Yes maybe the third option looks as the best one to me. Because when you introduce new method then there is a question: What all should it return in case of ASYNC version? It would make sense to return all ASYNC + SYNC observers but I think this will bring only more confusion. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-547) Resolving sync/async observer methods

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-547: ---------------------------------- So we have three options: * add overloaded {{resolveObserverMethods()}} with an extra {{boolean}} param to distinguish between {{fire()}} and {{fireAsync()}}, the original method follows {{fire()}} semantics * add a new method, e.g. something like {{resolveObserverMethodsForFireAsync()}} * do not add any methods, and let a consumer filter out sync/async observers as needed, i.e. sync + async observers for {{fireAsync()}} and sync for {{fire()}} The other question is ordering. IMO this depends on the result of CDI-541. I.e. if async observers would not honor ordering the set does not have to be "ordered" at all. > Resolving sync/async observer methods > ------------------------------------- > > Key: CDI-547 > URL: https://issues.jboss.org/browse/CDI-547 > Project: CDI Specification Issues > Issue Type: Clarification > Reporter: Jozef Hartinger > > There's the [BeanManager.resolveObserverMethods()|http://docs.jboss.org/cdi/api/2.0.ED...] method for resolving observer methods. > With addition of sync/async events and observers it is not unclear what the semantics of this methods are. We'll most likely need to add new or overloaded methods to make it possible to resolve observers for sync/async events. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2015