17:04:29 <antoine_sd> #startmeeting
17:04:29 <jbott> Meeting started Wed Jan 14 17:04:29 2015 UTC.  The chair is antoine_sd. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:29 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:04:30 <jbossbot> Title:3 MeetBot - Debian Wiki
17:04:32 <antoine_sd> hi all
17:05:01 <antoine_sd> today I wanted to start speaking about an early draft for the spec
17:06:06 <antoine_sd> and if we have time try to find a way to get unstuck on async events / operations
17:06:19 <antoine_sd> #topic EDR1
17:07:27 <antoine_sd> the idea would be to release a draft for march / april
17:08:06 <antoine_sd> it could contain the Java SE / EE split we talked about las week
17:08:13 <antoine_sd> hmm should
17:08:34 <antoine_sd> and I hope to have the java SE boot in it as well
17:08:59 <antoine_sd> now async event would be a bonus but I don't want to be too optimistic
17:09:06 <antoine_sd> any thought about that ?
17:09:34 <mp911de> async based on your changes, antoine_sd?
17:10:32 <antoine_sd> no : async on what we'll be ok by then
17:11:50 <antoine_sd> IMO we could come to a solution for fireAsync
17:12:09 <johnament> so this is the docs currently out on the google drive?
17:12:09 <antoine_sd> and the idea is not to specify something we are not happy with
17:12:16 <antoine_sd> yes
17:12:39 <antoine_sd> the pb with this doc is we should have different level in it
17:12:55 <antoine_sd> and right now a lot of things are mixed up in it
17:13:07 <johnament> agreed
17:13:42 <antoine_sd> the 2 main points are fire asynchronously and consuming asynchronously
17:13:56 <struberg> plus mutability
17:14:07 <antoine_sd> +1 struberg
17:14:30 <struberg> oh and @Priority
17:14:33 <struberg> means ordering
17:14:46 <struberg> and the 4th question is fire&forget vs Future kind
17:15:00 <struberg> think that should be all possible dimensions, right?
17:15:18 <antoine_sd> I don't have issue with mutability if it's doable and doesn't impact perf
17:15:27 <antoine_sd> yes strub
17:15:50 <johnament> why would mutability impact performance?
17:16:01 <struberg> well, if the impl did assume mutable event objects
17:16:12 <struberg> then we must not feed them to parallel observer methods
17:16:27 <antoine_sd> but I have the hope that we could agree on a point first before exploring all the dimensions
17:16:30 <struberg> you will get issues with visibility and locking
17:17:04 <antoine_sd> that's why this async feature is a bonus for EDR1
17:17:05 <struberg> basically we only can handle observers in parallel if they explicitly declared that they can handle this + the sender declares that the instance he sends can handle it as well
17:17:25 <johnament> i think that's a bit much
17:17:32 <johnament> more like it should be parallel
17:17:35 <struberg> think trough it john
17:17:44 <johnament> and if you don't want parallel don't send async
17:17:47 <struberg> thats the only safe way
17:17:57 <johnament> i agree, the object itself must be properly synchronized
17:17:59 <struberg> but what if you send async
17:18:05 <struberg> but the observer cannot handle it?
17:18:17 <struberg> as he e.g. relies on a @RequestScoped bean on the thread?
17:18:21 <johnament> @Observes(asyncSupported=false) ?
17:18:28 <struberg> TONS of pitfalls await us…
17:18:41 <struberg> johnament default should be false
17:18:51 <johnament> tons of more SO questions on why my code doesn't work
17:18:54 <johnament> struberg: 100% agree
17:18:56 <struberg> and you explicitely have to activate it
17:18:57 <antoine_sd> that's why I think mutability for async event shouldn't be in our scope
17:19:00 <struberg> for backward compat
17:19:27 <antoine_sd> but today
17:19:27 <struberg> antoine that is not up to us to specify
17:19:33 <struberg> cdi events have been mutable ever since
17:19:47 <struberg> that ship has sailed
17:20:01 <johnament> trying to introduce immutable anything in java is going to cause problems
17:20:09 <struberg> +1
17:20:11 <struberg> sad but true
17:20:20 <johnament> now your'e saying that an observer method can't call an increment method on some event payload
17:20:57 <johnament> its up to the guy writing the event payload to make sure his payload is properly thread safe (synchronized method, atomic etc)
17:21:20 <struberg> that is fine
17:21:21 <johnament> and the guy firing the event to say "why you didn't make this thread safe, here's a chicken"
17:21:37 <antoine_sd> Just for the record payload mutability is assumed but not specified
17:21:40 <antoine_sd> today
17:21:42 <struberg> but the observer method could do other things as well
17:21:56 <struberg> antoine we even use it in our very own events ;)
17:22:01 <johnament> it has to be
17:22:03 <struberg> and java instances are mutable by default
17:22:23 <johnament> right
17:22:38 <johnament> primtive wrappers are really the only ones that talk about immutability in java
17:22:38 <struberg> think about ProcessAnnotatedType et al
17:22:42 <struberg> all those are mutable
17:22:50 <struberg> and some collections
17:23:03 <struberg> Collections.unmodifyableList etc
17:23:05 <antoine_sd> let me state this again : I'm not saying it shouldn't be I say it should be specified
17:23:14 <struberg> ah oki antoine +1
17:23:24 <johnament> we should probably say that the extension observers cannot be async
17:23:47 <struberg> humm but that would actually be very neat ;)
17:24:17 <antoine_sd> That's the reason why I think we should first explore the limitation of not having async observer
17:24:17 <johnament> struberg: you think you'd be able to pull it off in OWB?
17:24:23 <mp911de> extensions are mostly written by devs with more awareness of what they are doing
17:24:24 <struberg> could speed up our boot
17:24:27 <antoine_sd> but only async firing
17:24:32 <struberg> if e.g. different jars could be scanned in parallel
17:24:49 <struberg> johnament owb could do, but the extensions could break
17:25:00 <struberg> we thought about that a few times already
17:26:16 <struberg> weld could do as easily I think
17:26:28 <struberg> but it really boils down to some extensions might get into troubles
17:26:51 <struberg> e.g. if they collect info in PAT and store them in standard maps
17:27:13 <struberg> and not in a ConcurrentHashMap
17:27:14 <struberg> etc
17:27:59 <antoine_sd> could we try to have a wider perspective
17:28:20 <antoine_sd> CDI 2.0 will be based on Java 8
17:28:34 <antoine_sd> where async operation is now super easy
17:28:59 <antoine_sd> So perhaps we don't need to specify async observers
17:29:10 <antoine_sd> but only async firing
17:29:24 <struberg> the problem is not spawning threasd
17:29:34 <struberg> but to setup our threadlocals properly
17:29:35 <mp911de> we still need to create awareness what async can cause
17:29:38 <struberg> and integrate in ee
17:30:13 <antoine_sd> if we fire event asynchronously we'll have to add this awareness
17:30:16 <mp911de> same as switch on 2nd level caching@JPA. Applications can run faster with it but it causes some effects
17:30:17 <antoine_sd> anyway
17:33:29 <antoine_sd> My problem is that for some of us this async feature is a all or nothing feature
17:34:12 <antoine_sd> there are a lot of dimension for async events
17:34:32 <antoine_sd> if we want to provide them all we probably get something wrong
17:35:11 <johnament> antoine_sd: i think my point with saying supportAsync = false is that there are times the observer method should not be invoked if we're async
17:35:24 <struberg> +1
17:35:32 <antoine_sd> ok with that
17:35:34 <struberg> especially if you mix in an old jar
17:36:06 <antoine_sd> it could even be the default value
17:36:12 <antoine_sd> for backward compatibility
17:36:21 <struberg> +1
17:36:26 <struberg> async should be an opt-in
17:36:27 <antoine_sd> so to have an async event
17:36:39 <struberg> fireAsync
17:36:44 <antoine_sd> you should fire it asynchronously and the observer should accept to be called asynchronously
17:36:46 <struberg> + if observer supports it
17:36:59 <struberg> other observers might get invoked in a different thread
17:37:11 <struberg> the ones who dont support it stay in the same thread
17:37:48 <antoine_sd> btw struberg nowhere in the spec it is said that events are called in the same thread ;)
17:38:06 <Jose_P> @antoine_sd : and this is a big hole in the spec ;)
17:38:10 <struberg> would need to look
17:38:13 <struberg> but probably true
17:38:24 <Jose_P> Yes, I checked that
17:38:24 <johnament> yes
17:38:35 <johnament> everyone i work with keeps telling me CDI already supports async events
17:38:57 <struberg> only with @Asynchronous on the method
17:39:03 <antoine_sd> someone could implement CDI by calling all observer in parallel and wait for their ending before giving control back
17:39:04 <struberg> and that is neat already
17:39:18 <Jose_P> the spec doesnt say that payloads should be immutable or thread safe
17:39:18 <antoine_sd> and as mutability is not specified...
17:39:24 <struberg> no, you would break the TCK
17:39:28 <struberg> :)
17:39:33 <Jose_P> and doesnt say that observers should be called in the same thread
17:39:44 <antoine_sd> no test in the tick about mutability
17:39:51 <Jose_P> so there is something not consistent here
17:40:53 <struberg> antoine but all EJB tests assume same thread
17:41:00 <struberg> as do most pure CDI test
17:41:05 <struberg> because of @RequestScoped...
17:41:58 <antoine_sd> yes but I prefer specified than assumed
17:42:09 <struberg> +1
17:42:44 <Jose_P> we need to specify something here yes
17:42:44 <antoine_sd> ok so can we start with this approach on async events?
17:43:14 <struberg> I see this really positive so far
17:43:37 <struberg> we did not specify anything broken yet and we have a very good overlook so far I think
17:44:38 <antoine_sd> yeah, it's not like this spec that specified broken EL name :)
17:44:39 <mp911de> what is the working mode for the spec parts? having a doc on google drive or submitting a pullrequest on github using asciidoc?
17:44:59 <Jose_P> antoine_sd  : can we state a few directions and move forward from there ?
17:44:59 <antoine_sd> next step --> Jira
17:45:03 <johnament> agree
17:45:12 <johnament> i think the cDI 2.0 spec will be flawless
17:46:57 <antoine_sd> that has to be said johnament  :)
17:47:25 <Jose_P> you should have said "I hope" ;)
17:47:41 <antoine_sd> #action create a jira ticket for async event
17:48:20 <johnament> can we talk about cdi boot?
17:48:30 <antoine_sd> yeah we didn't start to speak about adding bean @ runtime yet :-D
17:48:45 <struberg> lol beware
17:48:51 <antoine_sd> #topic java se boot
17:48:51 <struberg> nah could work
17:49:04 <johnament> i have a hard stop at 13:00
17:49:16 <johnament> it seems like there's two camps with se boot
17:49:28 <johnament> put it in CDI interface or put it in a separate interface
17:49:49 <johnament> I prefer the latter, because then we can control better programmatically when you should use boot
17:49:55 <johnament> and when not to use boot
17:50:27 <antoine_sd> I agree johnament
17:51:04 <struberg> +1 for separate package at least
17:51:10 <struberg> because the boot is not only for cdi
17:51:18 <antoine_sd> my only concerns are : CDI, CDIProvider and CDIBoot could be confusing for end user
17:51:32 <struberg> it is actually containers...
17:51:48 <johnament> well
17:51:53 <johnament> I think CDIContainer is a better name
17:51:58 <johnament> for this piece
17:52:06 <struberg> the api could also be used to boot a full embedded EE container
17:52:18 <struberg> that is really usable
17:52:19 <johnament> struberg: that's something for the EE8 spec
17:52:36 <struberg> but if we don't address it
17:52:50 <struberg> then we will be as broken as the embedded ejb container
17:53:08 <struberg> there is one such a thing already
17:53:13 <struberg> lets not repeat those errors
17:53:31 <antoine_sd> it's not costly to add a new package to think about the future
17:53:35 <johnament> struberg: looks like Antonio is already trying to address that.
17:53:50 <antoine_sd> remember johnament : EE umbrella spec never produce code
17:53:53 <johnament> for me, this is purely how to boot CDI, not a small portable EE runtime
17:53:54 <struberg> great
17:54:08 <johnament> antoine_sd: i know, this is likely a new spec
17:54:15 <johnament> speak of the devil!
17:54:43 <johnament> it would be cool if all other specs were implemented as CDI extensions
17:54:45 <agoncal> (sorry, mega late, hello everybody)
17:54:53 <johnament> then when you boot CDI magically those other specs suddenly work
17:55:24 <struberg> hiho agoncal
17:56:37 <johnament> so anyways
17:56:39 <johnament> for CDI booting alone
17:56:58 <johnament> javax.enterprise.inject.spi.container.CDIContainer ?
17:57:05 <Jose_P> fine for me
17:57:08 <antoine_sd> but the question of service integration is important for SE
17:57:28 <johnament> hmm
17:57:35 <johnament> we lost our leader...
17:57:35 <struberg> seems he wanted to paste something ;)
17:57:51 <antoine_sd> oops back
17:57:59 <struberg> wb spammer ;)
17:58:09 <struberg> what did you like to paste?
17:58:20 <johnament> were you pasting whole war and peace and novel?
17:59:24 <Jose_P> half of it would have been enough to be considered as spam ;)
18:00:10 <johnament> ok, gotta run
18:00:16 <antoine_sd> I didn't do it :)
18:00:17 <antoine_sd> ok I think we came on some agreement on this SE stuff as well
18:00:17 <antoine_sd> new package
18:00:22 <antoine_sd> new class
18:01:05 <agoncal> "  javax.enterprise.inject.spi.container" not very often that we see a depth of 5 packages in Java EE
18:01:25 <antoine_sd> #action ll add these conclusion to the SE ticket
18:01:37 <agoncal> what about just "javax.enterprise.inject.spi.CdiContainer" (one package less)
18:01:50 <antoine_sd> yes agoncal
18:02:04 <antoine_sd> we agreed on the principle not on the final name
18:02:21 <agoncal> alright (I'm still reading the transcript)
18:02:22 <antoine_sd> I have to leave you guys an other meeting
18:02:23 <antoine_sd> #endmeeting