[cdi-dev] Opening CDI F2F meeting to the community

Werner Keil werner.keil at gmail.com
Sat Sep 26 10:20:42 EDT 2015


Guys,

Only getting this digest now, but wanted to reply in any case. Sorry, I
could not make it this time. Primarily due to more travel coming up, as
DevoXX BE in Antwerp also invited me and 2 JSR 363 EG members to talk.

A significant number of EG members, especially those in Paris or France are
likely to go there, if they're not already at JavaOne (I should be at the
EC F2F and JavaOne, as long as PMO approves the travel request to go there
and tickets are still available ;-) thus I will meet almost all of those in
Paris now at either of these occasions or both.

Enjoy the stay and see you soon,

Werner

On Sat, Sep 26, 2015 at 2:55 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-383) Clarify that session context
>         is also destroyed at shutdown/undeploy
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12495319.1372413710000.40095.1442491260731 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109929#comment-13109929
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
>         observer        methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12578938.1437573301000.40527.1442496360658 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109994#comment-13109994
> ]
>
> 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/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-]
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
>         observer        methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12578938.1437573301000.40630.1442497561573 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110012#comment-13110012
> ]
>
> 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/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-]
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-547) Resolving sync/async
>         observer        methods
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12578938.1437573301000.40685.1442497980220 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110017#comment-13110017
> ]
>
> 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/BeanManager.html#resolveObserverMethods-T-java.lang.annotation.Annotation...-]
> 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 at sabot-durand.net>
> Subject: [cdi-dev] No meeting tomorrow
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBRpr14+t9-VnBcJAjUssyAChWZ53U+NAmnSAuhbgZ=
> 0Lw at mail.gmail.com>
> 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/attachment-0001.html
>
> ------------------------------
>
> Message: 6
> Date: Mon, 21 Sep 2015 09:14:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-20) @Observes(propagate = false)
>         - stop event propagation after being handled by an observer
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12420873.1286476929000.222.1442841240177 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>     [
> https://issues.jboss.org/browse/CDI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110833#comment-13110833
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-563) Event.fireAsync() - clarify
>         the usage of the returned CompletionStage
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12585540.1442846959000.631.1442847000016 at Atlassian.JIRA>
> 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 at sabot-durand.net>
> Subject: [cdi-dev] F2F participants
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBSeNMo=
> a8N6NdmMRJxUMncuGTpDdV2WyUesoLTMqPDQdw at mail.gmail.com>
> 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/attachment-0001.html
>
> ------------------------------
>
> Message: 9
> Date: Wed, 23 Sep 2015 10:03:07 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] Opening CDI F2F meeting to the community
> To: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CABu-YBQqFRYHWRi3=
> 6L0eK+i7SWKdEu-9Uu-BUeTU5dGzgjg+w at mail.gmail.com>
> 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/attachment-0001.html
>
> ------------------------------
>
> Message: 10
> Date: Sat, 26 Sep 2015 08:55:00 -0400 (EDT)
> From: "Martin Kouba (JIRA)" <issues at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-515) Allow to obtain Bean
>         metadata from javax.enterprise.inject.Instance
> To: cdi-dev at lists.jboss.org
> Message-ID:
>         <JIRA.12564784.1425452571000.17380.1443272100093 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
>      [
> https://issues.jboss.org/browse/CDI-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> 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 at 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
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150926/9c4a85ac/attachment-0001.html 


More information about the cdi-dev mailing list