Send cdi-dev mailing list submissions to cdi-dev(a)lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/cdi-dev or, via email, send a message with subject or body 'help' to cdi-dev-request(a)lists.jboss.org You can reach the person managing the list at cdi-dev-owner(a)lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cdi-dev digest..." Today's Topics: 1. [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy (Martin Kouba (JIRA)) 2. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods (Martin Kouba (JIRA)) 3. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods (Tomas Remes (JIRA)) 4. [JBoss JIRA] (CDI-547) Resolving sync/async observer methods (Martin Kouba (JIRA)) 5. No meeting tomorrow (Antoine Sabot-Durand) 6. [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer (Martin Kouba (JIRA)) 7. [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage (Martin Kouba (JIRA)) 8. F2F participants (Antoine Sabot-Durand) 9. Opening CDI F2F meeting to the community (Antoine Sabot-Durand) 10. [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance (Martin Kouba (JIRA)) ---------------------------------------------------------------------- Message: 1 Date: Thu, 17 Sep 2015 08:01:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12495319.1372413710000.40095.1442491260731(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-383: ---------------------------------- Well, an HTTP session does not have to be destroyed after a container is shut down. This is not defined in the servlet spec and I did not find anything relevant in the Java EE spec. See also CDITCK-482 comments. However, if we redefine this and state that it's destroyed after an HTTP session is invalidated, we would probably break backward compatibility (see also CDI-497). > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Luk?a > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026) ------------------------------ Message: 2 Date: Thu, 17 Sep 2015 09:26:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12578938.1437573301000.40527.1442496360658(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ 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.EDR1/javax/enterprise/inject/spi/BeanMa...] 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) ------------------------------ Message: 3 Date: Thu, 17 Sep 2015 09:46:01 -0400 (EDT) From: "Tomas Remes (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12578938.1437573301000.40630.1442497561573(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ 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.EDR1/javax/enterprise/inject/spi/BeanMa...] 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) ------------------------------ Message: 4 Date: Thu, 17 Sep 2015 09:53:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async observer methods To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12578938.1437573301000.40685.1442497980220(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ 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.EDR1/javax/enterprise/inject/spi/BeanMa...] 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) ------------------------------ Message: 5 Date: Mon, 21 Sep 2015 07:10:08 +0000 From: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Subject: [cdi-dev] No meeting tomorrow To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CABu-YBRpr14+t9-VnBcJAjUssyAChWZ53U+NAmnSAuhbgZ= 0Lw(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" Hi Guys, I'll focus on the F2F meeting preparation. So no meeting tomorrow Regards, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150921/f0e51a71/at... ------------------------------ Message: 6 Date: Mon, 21 Sep 2015 09:14:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false) - stop event propagation after being handled by an observer To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12420873.1286476929000.222.1442841240177(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ 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) ------------------------------ Message: 7 Date: Mon, 21 Sep 2015 10:50:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify the usage of the returned CompletionStage To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12585540.1442846959000.631.1442847000016(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 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) ------------------------------ Message: 8 Date: Wed, 23 Sep 2015 08:20:50 +0000 From: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Subject: [cdi-dev] F2F participants To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CABu-YBSeNMo= a8N6NdmMRJxUMncuGTpDdV2WyUesoLTMqPDQdw(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" Hi guys, So the meeting is starting friday in Paris. So far beyond the Red Hat guys I have only 2 or 3 participants: - Antonio - Emily - Werner (maybe) Did I forget someone ? Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/acb3047c/at... ------------------------------ Message: 9 Date: Wed, 23 Sep 2015 10:03:07 +0000 From: Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Subject: [cdi-dev] Opening CDI F2F meeting to the community To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Message-ID: <CABu-YBQqFRYHWRi3= 6L0eK+i7SWKdEu-9Uu-BUeTU5dGzgjg+w(a)mail.gmail.com&gt; Content-Type: text/plain; charset="utf-8" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150923/7533fdae/at... ------------------------------ Message: 10 Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT) From: "Martin Kouba (JIRA)" <issues(a)jboss.org&gt; Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean metadata from javax.enterprise.inject.Instance To: cdi-dev(a)lists.jboss.org Message-ID: <JIRA.12564784.1425452571000.17380.1443272100093(a)Atlassian.JIRA&gt; Content-Type: text/plain; charset=UTF-8 [ 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) ------------------------------ _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. End of cdi-dev Digest, Vol 58, Issue 15 ***************************************