17:06:53 <antoine_sd> #startmeeting
17:06:53 <jbott> Meeting started Wed Feb 25 17:06:53 2015 UTC.  The chair is antoine_sd. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:06:53 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:06:55 <jbossbot> Title:3 MeetBot - Debian Wiki
17:07:11 <antoine_sd> #topic async event and contexts support
17:07:46 <antoine_sd> reading this thread
17:07:47 <antoine_sd> http://cdi-development-mailing-list.1064426.n5.nabble.com/Enhancing-SPI-to-support-async-operation-for-contexts-td5711006.html
17:07:48 <jbossbot> Title:3 CDI Development mailing list - Enhancing SPI to support async operation for contexts
17:08:24 <antoine_sd> I feel that most of you think that it would be a bad idea to support request or session scope in async operation
17:08:32 <antoine_sd> thus async event
17:08:36 <struberg> antoine_sd I had another idea today
17:08:45 <struberg> (sometime it takes a while to develop good things)
17:08:57 <struberg> we do NOT need an explicit @Async annotation at the observers
17:09:09 <struberg> we CAN differntiate on the methods signatore
17:09:09 <antoine_sd> \0/
17:09:11 <struberg> signature
17:09:13 <struberg> means
17:09:22 <struberg> if the method returns CompletableFuture (or whatever)
17:09:27 <struberg> -> async aware
17:09:34 <struberg> if it returns void -> keep it on same thread
17:09:44 <struberg> sooooo easy
17:09:48 <struberg> and perfectly backward compat
17:09:56 <johnament> hmm
17:10:02 <struberg> took me 3 weeks now to come up with this simple rule
17:10:10 <johnament> weld currently allows you to do public SomeObject foo(@Observes Something s)...
17:10:28 <struberg> hmm thats not allowed per the spec isn'T?
17:10:48 <antoine_sd> I checked that
17:10:55 <antoine_sd> because I had the same idea
17:10:56 <johnament> that’s what i thought, but apparently weld doesn’t complain about it
17:11:07 <johnament> it could be not specified in the spec
17:11:09 <johnament> that you can’t do that
17:11:23 <antoine_sd> it's not said that observer should return void
17:11:52 <struberg> what does weld do with the return value? ^^
17:12:04 <johnament> i haven’t the foggiest
17:12:12 <johnament> as far as i know it’s dereferenced
17:12:14 <antoine_sd> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#observer_methods
17:12:16 <jbossbot> Title:3 Contexts and Dependency Injection for the Java EE platform
17:12:33 <antoine_sd> the "void" is not in the specification
17:12:47 <johnament> yep
17:12:50 <antoine_sd> now the pb with this idea
17:13:08 <antoine_sd> is that you have to return this completablefuture or whatever
17:13:29 <struberg> nah, only the signature needs to be
17:13:38 <struberg> you can return null as well
17:13:38 <antoine_sd> the event dispatcher should give something to the method to deal with that
17:13:55 <Jose_P> who is going to build this CompletionStage ?
17:14:11 <antoine_sd> honestly find this more confusing than @async
17:14:39 <antoine_sd> and struberg It wasn't the topic
17:14:48 <Jose_P> I dont think we should give the responsability to build this CompletionStage to the observer methods
17:14:49 <antoine_sd> the topic was about contexts support for async events
17:15:09 <Jose_P> that would make very hard the building of an observer
17:15:14 <Jose_P> which should be very simple
17:15:43 <johnament> what if we make the completion stage a param in the observer method?
17:16:08 <antoine_sd> I prefer this idea johnament
17:16:31 <antoine_sd> it would allow user to play with the async operation
17:17:20 <Jose_P> you mean pass a CS as a param so that the observer can return it ?
17:18:37 <johnament> no
17:18:42 <struberg> that badly mixes up input and output
17:18:44 <johnament> i guess we need future
17:18:46 <johnament> not stage
17:18:57 <struberg> stage can build future
17:19:00 <Jose_P> ok, so same question with a Future then ;)
17:19:01 <johnament> you would have to do future.obtrudeValue(something)
17:19:15 <johnament> or on failure obtrudeException
17:19:33 <johnament> but here’s the thing
17:19:44 <johnament> two observes could then obtrude on one another
17:20:42 <antoine_sd> honnestly guys I think it's simpler to add the asycSupport on the observer
17:21:23 <johnament> agreed
17:21:32 <Jose_P> agreed
17:22:05 <antoine_sd> ok so event if I'm not a fan of it, let's go in that direction
17:22:26 <antoine_sd> now should it be a new member in @Observes or a new annotation ?
17:22:30 <Jose_P> it depends on what we understand in "asyncsuport" on the observer
17:23:06 <Jose_P> I think we should see that as a broader feature, which is the async support in general
17:23:13 <johnament> do we expect to add more async stuff to CDI spec?
17:23:17 <johnament> like async bean methods?
17:23:19 <antoine_sd> #agreed async event should be enable at producer and consumer to be effective
17:23:31 <Jose_P> having a way to tell CDI that this method can be called asynchronously
17:23:49 <antoine_sd> johnament I don't think so
17:23:57 <johnament> oh
17:24:02 <Jose_P> probably with an @Async annotation, or maybe something else
17:24:13 <struberg> would be cool to have @Asynchronous on EE level
17:24:19 <antoine_sd> except if we have a special CDI support for contexts in async
17:24:23 <johnament> i would make it a separate annotation either way i think, just in case we decide at some point to add async support to bean methods
17:24:23 <struberg> but that would have to be dealt with like interceptors
17:24:36 <antoine_sd> hence the current topic that was totally squeezd
17:24:53 <Jose_P> because the reflection we're having on observer we can have it on interceptors too
17:25:09 <antoine_sd> johnament it is so simple to do async with java 8 I don't see the interest
17:25:20 <antoine_sd> unless we add something for contexts
17:25:22 <johnament> yeah i know
17:25:29 <johnament> but you did add a veto annotation
17:25:35 <struberg> has nothing to do with java8 async
17:25:47 <Jose_P> and then the reflection on contexts is also broader than just the observers
17:25:50 <struberg> has more to do with ee-cuncurrency spec finally working fine with @RequestScoped
17:25:52 <johnament> meh, will be a nice tutorial “how to write an async interceptor for cdi beans"
17:26:04 <struberg> all the JavaEE async stuff is not about starting threads
17:26:12 <struberg> it's mostly about setting up those threads correctly
17:26:21 <struberg> (tx, @RequestScoped, etc)
17:27:04 <antoine_sd> I don't agree struberg
17:27:18 <antoine_sd> @Asynchrtonous in EJB is about starting thread
17:27:27 <antoine_sd> and we are talking about that right now
17:27:41 <struberg> antoine, the whole reason for having @Asynchronous is that this thread is SET UP correctly
17:27:50 <struberg> starting new threads is an SE thing
17:27:52 <johnament> ejb async was done before executors though
17:28:04 <struberg> the problem is that those threads have no ThreadLocals for various EE features
17:28:06 <antoine_sd> now we have executor so what's the point
17:28:15 <struberg> and thus @Asynchronous to fix this shortcoming
17:28:30 <antoine_sd> for EE the concurrent spec
17:28:31 <struberg> antoine, the concurrency-utils Executor does NOT start @RequestScoped context...
17:28:35 <antoine_sd> gives us what we need
17:28:40 <struberg> no it's broken
17:28:44 <antoine_sd> and for SE we don't carer
17:28:49 <struberg> at least the wording
17:28:57 <struberg> if some containers start the rq ctx then fine
17:29:00 <struberg> but it's non-portable
17:29:08 <antoine_sd> struberg
17:29:23 <antoine_sd> we didn't decide anything about request
17:29:33 <antoine_sd> did you read the thread I put at the begining
17:29:43 <antoine_sd> before you changed the topic ?
17:30:12 <antoine_sd> a lot of people don't want to have request or session support for async operation
17:30:24 <antoine_sd> that's why I said
17:30:33 <struberg> I agree with that
17:30:44 <antoine_sd> having an annotation is useless unless we provide something for contexts support
17:30:55 <antoine_sd> that we don't seem to be about to do
17:31:09 <struberg> we should differentiate between context support and context 'propagation'
17:31:11 <antoine_sd> so what would be the interest of @Async
17:31:20 <antoine_sd> in regard of Java 8 async API
17:31:33 <struberg> new contexts, like @Asynchronous
17:31:52 <struberg> no session ctx
17:32:03 <struberg> there was a very good reason for it in EJB
17:32:09 <struberg> remember the long discussion
17:32:23 <struberg> jjsnyder should be able to give more input as well
17:33:06 <struberg> Request Ctx propagation only makes sense if the original thread gets suspended
17:33:18 <antoine_sd> could answer the question about the advantage of having @Async on Java 8 async api?
17:33:30 <struberg> because nowadays (albeit not worded explicitly) most people and devs assume it's single-threaded accessed
17:33:55 <struberg> propagation of SessionScoped ctx _could_ be good to look at
17:34:03 <struberg> (session is already concurrently used)
17:34:21 <struberg> BUT we need to be careful about session cleanup, replication, etc
17:34:51 <struberg> that only makes sense for cases where the code in the original thread waits for the completion of the observers I'd say
17:35:34 <Jose_P> struberg: to answer that question we need to know exactly what ppl can do with the Context object
17:36:13 <johnament> you know what
17:36:19 <johnament> if async is so easy, do we even need it?
17:36:31 <johnament> can’t you just do async inside of the observer method
17:36:31 <struberg> it's not easy
17:36:33 <johnament> and be done with this
17:36:55 <struberg> it's just poorly understood and people only have it failing in production under heavy lod
17:36:56 <Jose_P> it's the same kind of stuff than asking ppl to return a CompStage
17:36:56 <struberg> load
17:37:33 <struberg> heh johnament that is another way, but we have this already since CDI-1.0
17:37:35 <jbossbot> jira [3CDI-1] Clarify how resource producer fields (for persistence contexts) interact with transaction propagation [10Resolved (Rejected) Clarification,7 Major,6 Pete Muir] https://issues.jboss.org/browse/CDI-1
17:37:46 <struberg> just have an @Observes on an @javax.ejb.Asynchronous method
17:37:49 <struberg> works like a charm
17:38:22 <struberg> of course you need to have the  Future as part of the event parameter to be able to await it's completion (if needed)
17:38:32 <struberg> but all that works since 5 years already
17:38:51 <struberg> of course not with pure CDI, but on any EE container
17:39:00 <antoine_sd> regarding events we agreed to provide a solution out of the box
17:39:14 <antoine_sd> we were talking about async operation support
17:39:18 <struberg> (that was one of my very first questions btw)
17:39:19 <antoine_sd> beyond events
17:39:21 <Jose_P> integrating it in CDI will allow ppl to use if in Java SE
17:39:32 <struberg> jose_p you can do that as well already
17:39:40 <struberg> just use EJBContainer
17:39:52 <struberg> EJB even has an own API already to boot it up in embedded mode in Java SE
17:39:58 <struberg> and this will ALSO boot the CDI container
17:40:04 <struberg> what it misses is ContextControl
17:40:21 <struberg> so you have no way to start/stop/assign our standard contexts
17:40:31 <Jose_P> so what is the point on having a CDI container ? ;)
17:40:38 <struberg> ContextControl ;)
17:40:45 <struberg> that's really the only benefit
17:40:49 <struberg> but that's worth it!
17:40:54 <Jose_P> I think it makes sense to add that to CDI
17:41:00 <struberg> sure it does
17:41:06 <antoine_sd> that's a good ad to use Spring IMO :)
17:41:23 <struberg> nah, thats just good marketing on Spring side
17:41:27 <Jose_P> plus javax.ejb.Asynchronous has constraints : you need a session bean method that returns Future
17:41:39 <struberg> and a poor decision by some container vendors to _not_ support the portable EJBContainer embedded api
17:41:52 <struberg> as it is not required to be implemented by the ejb spec
17:41:55 <Jose_P> so you need to provide a future, that will probably be provided by the ES inside your method
17:42:08 <struberg> it's only _IF_ a container is available in an embedded fashion
17:42:32 <struberg> jose_p sorry, ecantparse :)
17:42:57 <antoine_sd> struberg we are not working on melting CDI and EJB what's the point here ?
17:43:27 <struberg> I hope we are working on providing a benefit for our users
17:43:51 <struberg> what is the benefit of adding something which can be done already?
17:43:51 <antoine_sd> yes and a big part of it will be in Java SE
17:44:17 <antoine_sd> without building a stack from, out of space because it's possible to do it
17:46:03 <antoine_sd> yes with Spring so let's go to the swimming pool ;)
17:46:04 <Jose_P> struberg: sorry I really dont follow you, do you really think we should tell ppl that need async calls "just use an EJB for it" ??
17:46:12 <Jose_P> it doesnt make any sens
17:46:15 <Jose_P> sense*
17:46:17 <antoine_sd> +1000000000000
17:46:28 <antoine_sd> WTF we are the CDI EG
17:46:41 <struberg> but we still are in JavaEE
17:46:45 <Jose_P> I'm looking for the E ;o)
17:46:48 <struberg> so we should not duplicate functionality
17:46:57 <Jose_P> it's clearly not a duplication
17:47:28 <Jose_P> it's a broader feature, more general, and we should concentrate on the impact it has on contexts
17:47:32 <antoine_sd> what are you talking about struberg?
17:47:34 <Jose_P> namely HTTP contexts
17:47:58 <struberg> antoine_sd @Asynchronous
17:48:09 <struberg> I'm still a fan of extracting this over to concurrency-utils
17:48:18 <struberg> and then both ejb and cdi can use it
17:48:21 <struberg> even in SE…
17:48:37 <antoine_sd> we agree on that struberg
17:48:49 <antoine_sd> that's why I asked 10 times what would be the benefit
17:48:56 <antoine_sd> of it
17:49:15 <antoine_sd> not what would be the drawback
17:49:43 <struberg> benefit would be huge
17:49:59 <antoine_sd> ok
17:50:04 <struberg> and we even could improve the @Asynchronous propably
17:50:45 <struberg> e.g. define what features of EE are to be supported on the new thread
17:51:08 <antoine_sd> would you write a doc or a mail explaining us this huge benefit in regard of Java 8 async API
17:51:15 <antoine_sd> because I don't get it
17:51:40 <struberg> the Java8 async support doesn't deal with all the container ThreadLocals
17:51:50 <struberg> think about security, tx, EJB Session
17:51:55 <struberg> all those things are stored in ThreadLocals
17:52:08 <struberg> and NONE of this is setup if you use plain Java Thread handling
17:52:17 <struberg> do we agree so far?
17:52:36 <antoine_sd> ok
17:52:39 <struberg> (that was the reason why starting new threads in EE was FORBIDDEN before EE5 or 6)
17:52:54 <Jose_P> it is still forbidden in 7
17:53:14 <struberg> jose_p yes, thats what concurrency-utils and @Asynchronous is for
17:53:16 <antoine_sd> but if we use concurent spec to get executor
17:53:18 <Jose_P> you can use this ManagedES, bt not launch your own threads
17:53:28 <struberg> it btw also breaks most CDI containers in JavaSE ;)
17:53:42 <Jose_P> in the EE context we can rely on ManagedES yes
17:53:54 <Jose_P> and in SE use a plain ES I think
17:54:10 <struberg> cannot work without decoration from CDI side
17:54:12 <Jose_P> that could be provided by the user, or use the CommonForkJoinPool
17:54:21 <struberg> because even CDI uses lots of ThreadLocals
17:54:29 <struberg> under the hood
17:56:57 <struberg> hmm, all asleep? :)
17:57:12 <Jose_P> Do we have a decision to make on async events ?
17:57:14 <antoine_sd> no. Was reading
17:57:18 <antoine_sd> https://docs.google.com/document/d/1pDO7gru6YuEyTDdK3XBozvXZYucT9uC7McZMffSZun4/edit?usp=sharing
17:57:18 <jbossbot> Title:3 Asynchronous operations in CDI workshop doc - Google Docs
17:57:23 <antoine_sd> I wrote 2 months ago
17:57:30 <Jose_P> Since we are only 3 in this conversation... I guess we cant ?
17:57:35 <antoine_sd> ok regarding events
17:57:50 <antoine_sd> we agreed on the activation on consumer side
17:58:05 <struberg> which part antoine?
17:58:28 <struberg> antoine_sd yes, sender and consumer opt-in
17:58:37 <struberg> would be the best for backward compat
17:58:53 <struberg> and in that case we don't need any @Asynchronous
17:59:03 <antoine_sd> now we don't know what will be the opt)--in on the consumer side
17:59:25 <antoine_sd> a new annotation or a member in @Observes
17:59:35 <struberg> could be auto-detect on return type as well
17:59:43 <struberg> even if weld allows return values
17:59:59 <antoine_sd> #action launch a thread on the consumer side opt-in
18:00:09 <struberg> if we say all methods which have a return Future are async capable...
18:00:17 <struberg> not sure if people will grasp that
18:00:17 <antoine_sd> -1
18:00:19 <Jose_P> I think we already did that 2 weeks ago
18:00:28 <Jose_P> -1
18:00:31 <struberg> but might be only a matter of getting used to
18:00:47 <struberg> oki then @Observes method or new annotation
18:00:50 <Jose_P> exposing that = exposing a lot of complexity
18:00:52 <struberg> where I prefer the new annotation
18:00:57 <struberg> because that is backward compat
18:01:09 <struberg> the jar which uses this will also run on CDI-1.0… CDI-1.2 containers
18:01:10 <jbossbot> jira [3CDI-1] Clarify how resource producer fields (for persistence contexts) interact with transaction propagation [10Resolved (Rejected) Clarification,7 Major,6 Pete Muir] https://issues.jboss.org/browse/CDI-1
18:01:28 <antoine_sd> ok let's discusss that offline on the ML with more people
18:01:33 <struberg> if you change the @Observes method then it will be broken for older containers
18:01:52 <antoine_sd> time's up guys
18:01:55 <antoine_sd> #endmeeting