Mark,
What do you mean by @Event?
CDI contains the Event interface, no annotation.
Are you proposing a new annotation or was it a typo?
So did you mean
@Async
private Event<UserLoggedIn> userLoggedInEventSource;
below?
Werner
On Tue, Feb 10, 2015 at 10:31 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
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. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg)
2. Re: Async events. We need ideas to improve CDI-499 (Mark Struberg)
3. Re: Async events. We need ideas to improve CDI-499
(Jozef Hartinger)
4. Re: Async events. We need ideas to improve CDI-499
(Jozef Hartinger)
5. Re: Async events. We need ideas to improve CDI-499
(Jozef Hartinger)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Feb 2015 07:53:30 +0000 (UTC)
From: Mark Struberg <struberg(a)yahoo.de>
Subject: Re: [cdi-dev] Async events. We need ideas to improve CDI-499
To: Jos? Paumard <jose.paumard(a)gmail.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
Message-ID:
<1995246191.1465726.1423554810674.JavaMail.yahoo(a)mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Hi Jos?!
Backward compatibility is perfectly fine with both approaches. People can
use BeanManager#fire() instead of the newly proposed
BeanManager#fireAsync().
My point is that many people will simply not be able to use fireAsync()
because as a framework developer you really need to code defensive. Without
an explicit opt-in on observer side fireAsync() can basically only be used
in situations where you _exactly_ know all your observers...
An own @Async annotation would also be nice as it could not only be used
at @Observes but also for @Event
@Inject
@Async
@Event
private Event<UserLoggedIn> userLoggedInEventSource;
The benefit of an own @Async annotation over extending e.g. the @Event
annotation is that it would be perfectly backward compatible. This code
would also run on CDI-1.0 .. 1.2 containers (as all annotations which are
not available on the classpath will simply be ignored by the JVM.
LieGrue,
strub
On Tuesday, 10 February 2015, 8:41, Jos? Paumard <jose.paumard(a)gmail.com>
wrote:
>Mark,
>It vas never been in the mind of anyone to modify the way things work
currently. Keeping the backward compatibility is a prerequisite to any kind
of modification or improvment added to the spec. This has already been said
and written several times.
>Jos?
>Le 10 f?vr. 2015 07:37, "Mark Struberg" <struberg(a)yahoo.de> a ?crit
:
>
>Good morning!
>>
>>
>>Folks, please think a bit further.
>>
>>
>>I'll give you a practical example. What should a developer do first? Eat
their own dog food...
>>
>>Where does this apply to us? Means where do _we_ use CDI events? Right,
in CDI Extensions.
>>
>>So ask yourself a simple question: if we like to leverage async events
in CDI extensions then how could we do that? Your suggestion was to just
use fireAsync instead of fire, right?
>>
>>Now imagine what would happen if we would do that... I'd say most real
world apps would go BOOOOMMMMM and not even finish the start. Simply
because most CDI extensions are not built to be executed in parallel. Just
look at Extensions who collect information about classes in @Observes
ProcessAnnotatedType. Most of the time they collect this in a
non-concurrent Set or List
>>
>>private final Collection<AnnotatedType<?>> messageBundleTypes = new
HashSet<AnnotatedType<?>>();
>>
>>
>>If you fire the ProcessAnnotatedType event in parallel then you will
blow up. And this was just ONE example. There are tons of other CDI
Extension Events which would have the same result if switched to fireAsync.
>>
>>
>>Now think about what would happen IF we would have an @Async on the
observer?
>>
>>All would work. Old extensions still will get triggered in the same
thread, but extensions with @Async would leverage parallel behaviour.
>>
>>
>>I hope this practical sample makes it more clear why I think that most
of the time we cannot simply switch to fireAsync if there is old code
around which is not under your full control.
>>
>>
>>LieGrue,
>>strub
>>
>>
>>
>>
>>
>>
>>> On Monday, 9 February 2015, 20:56, Romain Manni-Bucau <
rmannibucau(a)gmail.com> wrote:
>>> > I guess 2 is not a real need - and at least not why people voted for
>>> this feature. Difference between fireAsync and @Async is who decides
>>> to be asynchronous. Caller (fire) should clearly be able IMO - with
>>> all the warning we can put in the spec to say it should be done with
>>> compatible scopes. The second one is less important for me cause you
>>> can already do it with concurrency utilities (ee one or not) pretty
>>> easily.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>>
http://www.tomitribe.com
>>>
http://rmannibucau.wordpress.com
>>>
https://github.com/rmannibucau
>>>
>>>
>>> 2015-02-09 20:33 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
>>>> Btw, did we already cover the 'fireAndForget' vs
>>> 'fireAndWait' use cases?
>>>>
>>>> 1. fireAndForget: this is basically what you get today if you use
>>> @javax.ejb.Asynchronous on an @Observer method
>>>>
>>>> 2.) fireAndWait: call all observers in a new thread and only return
after
>>> all observer methods did finish.
>>>>
>>>>
>>>>
>>>> Did we already agree on one of the 2 modi? If not, do we like to
support
>>> both? And if so, how to tell the CDI container which of the 2 modes to
use for
>>> each observer?
>>>>
>>>>
>>>> If you answer the last question with yes then we might need some
>>> annotation/additional info on the observer method anyway. And then we
are back
>>> on our @Async annotation on the observer method...
>>>>
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> On Monday, 9 February 2015, 18:43, Romain Manni-Bucau
>>> <rmannibucau(a)gmail.com> wrote:
>>>>> Guys I'm not sure to fully get the jira description now. Can you
try
>>>>> to rephrase it a bit?
>>>>>
>>>>> Here what I see:
>>>>>
>>>>> 1) fireAsync (+1) is clear
>>>>> 2) (part I dont fully get) asyncSupported: is it mandatory? If yes
I
>>>>> think this API is not usable (=user friendly) and I would just
suggest
>>>>> it is on by default and to remove this flag
>>>>>
>>>>>
>>>>> Can it break apps? Yes as mentionned by Mark. Will it break apps?
No
>>>>> since it is not yet used and this is surely what we want. I fully
>>>>> understand all the mentionned pitfalls - but let me say
@RequestScoped
>>>>> is by definition as broken as this today since you can't
associate
>>> it
>>>>> with a request for the exact same reason. What I mean is: if you
>>>>> choose async then you assume it so I think we shouldn't protect
the
>>>>> user from pitfalls then...in particular since we can't protect
him
>>>>> from other as vicious issues.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau
>>>>>
http://www.tomitribe.com
>>>>>
http://rmannibucau.wordpress.com
>>>>>
https://github.com/rmannibucau
>>>>>
>>>>>
>>>>> 2015-02-09 18:28 GMT+01:00 Antoine Sabot-Durand
>>> <antoine(a)sabot-durand.net>:
>>>>>> Mark I understand your concern, now can you understand the one
we
>>> discussed about the fact of having to enable async at both ends is a
source of
>>> confusion for end users and will give a bad perception of the spec.
>>>>>>
>>>>>> So could we figure something user friendly to enable async
event?
>>>>>>
>>>>>> Antoine
>>>>>>
>>>>>>
>>>>>>> Le 9 f?vr. 2015 ? 12:00, Mark Struberg
>>> <struberg(a)yahoo.de> a ?crit :
>>>>>>>
>>>>>>> But that might defeat pluggabilgity. Basically no framework
can
>>> use fireAsync in that case.
>>>>>>>
>>>>>>> Imagine a UserLoggedIn event. For most observers it is
>>> perfectly fine to observe this in a new thread. But some might need to
access
>>> the session -> boom. Which means that all frameworks have to fall back
to the
>>> 'safe' fire() instead of fireAsync()...
>>>>>>>
>>>>>>> That will leave us half-broken as it totally defeats the
usage
>>> of this cool feature...
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Monday, 9 February 2015, 11:51, Antoine
Sabot-Durand
>>> <antoine(a)sabot-durand.net> wrote:
>>>>>>>>> Mark,
>>>>>>>>
>>>>>>>>
>>>>>>>> During last meeting we didn?t say there wasn?t use
case
>>> that would break
>>>>>>>> existing observer, we said that since we keep the
current
>>> fire() method there is
>>>>>>>> backward compatibility. User trying to send fireAsync()
and
>>> experiencing error
>>>>>>>> with legacy observer will have to fall back to fire().
>>>>>>>>
>>>>>>>> Antoine
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Le 9 f?vr. 2015 ? 11:12, Mark Struberg
>>> <struberg(a)yahoo.de> a ?crit :
>>>>>>>>>
>>>>>>>>> Hi Jozef, here we go!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1.) accessing @RequestScoped beans in your
Observer
>>>>>>>>>
>>>>>>>>> 2.) accessing @SessionScoped beans in your
Observer
>>>>>>>>> 3.) accessing/relying on any transactional
behaviour.
>>> This is really a
>>>>>>>> boomer. Basically you break transactions that way.
>>>>>>>>>
>>>>>>>>> 4.) accessing @TransactionScoped beans in your
Observer
>>>>>>>>>
>>>>>>>>> 5.) access/relying on any ThreadLocal in your
Observer
>>>>>>>>> 6.) accessing attached entities in your Observers
(they
>>> must only get
>>>>>>>> accessed from a very single Thread according to the
JPA
>>> spec)
>>>>>>>>> 7.) using an EntityManager in a parallel thread
might
>>> give you unexpected
>>>>>>>> results.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There might be quite a few more. E.g. we need to
>>> specify that EJBs and
>>>>>>>> other EE features need to work in such a new Thread,
etc
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> LieGrue,
>>>>>>>>> strub
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tuesday, 3 February 2015, 9:40, Jozef Hartinger
>>>>>>>> <jharting(a)redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We should enumerate all the arguments
supporting
>>> async flag on an
>>>>>>>> observer. So far I have only seen one:
>>>>>>>>>>
>>>>>>>>>> - an observer accessing @RequestScoped state
would
>>> no longer be able
>>>>>>>>> to do so since it would be run in a worker
thread
>>>>>>>>>>
>>>>>>>>>> I am eager to hear more arguments as this
single
>>> one may not be
>>>>>>>>> enough to justify the observer-async-flag
design
>>> decision.
>>>>>>>>>>
>>>>>>>>>> Remember that introducing fireAsync() itself
does
>>> not break any
>>>>>>>>> existing application because existing
applications
>>> are using fire().
>>>>>>>>> It's when an existing application / library
is
>>> modified to use
>>>>>>>>> fireAsync() when the problem may occur. Such
change
>>> should not be
>>>>>>>>> done blindly. As with any other change, an
author
>>> should consider
>>>>>>>>> possible consequences of the change. Clearly
>>> documenting the fact
>>>>>>>>> that fireAsync() processing is done in a
different
>>> thread with a
>>>>>>>>> different @RequestScoped state may be
sufficient.
>>>>>>>>>>
>>>>>>>>>> Jozef
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 02/02/2015 03:43 PM, Antoine Sabot-Durand
wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
https://issues.jboss.org/browse/CDI-499
comes
>>> after a lot of
>>>>>>>> discussion about async events.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think the solution exposed here is quite
>>> satisfying, yet the idea
>>>>>>>> to need to activate async behaviour on the observer
side
>>> doesn?t please a lot of
>>>>>>>> us. It?ll be confusing for users to have to activate
async
>>> from the firing end
>>>>>>>> and consuming end to see it work :-(.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I?d like to see alternative proposal to
have
>>> this new feature as
>>>>>>>> user friendly as possible and keep the
retro-compatibility
>>> aspect. We should
>>>>>>>> find a better solution on our next meeting on
wednesday.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Antoine
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
_______________________________________________
>>>>>>>>> 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.
>>>
>>>>>
>>>>>>>>>>
>>>>>>>>>>
_______________________________________________
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>>>
>>
>>_______________________________________________
>>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.
>
>
_______________________________________________
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 51, Issue 21
***************************************