June 2015 - cdi-dev - Jboss List Archives

Getting injection point from Bean#create

by arjan tijms

Hi, In a producer method it's trivial to get access to an InjectionPoint instance representing the point where the value produced by the producer will be injected. When registering a Bean manually from an extension using AfterBeanDiscovery#addBean, this is not immediately obvious. After some fumbling with the CDI APIs I came up with the following code that seems to work on both Weld and OWB (didn't test CanDI yet). It uses a small "dummy" class, which is used to grab an InjectionPoint off: In a Bean: public Object create(CreationalContext<Object> creationalContext) { InjectionPoint injectionPoint = (InjectionPoint) beanManager.getInjectableReference( resolve(beanManager, InjectionPointGenerator.class).getInjectionPoints().iterator().next(), creationalContext ); With InjectionPointGenerator being the following class: public class InjectionPointGenerator { @Inject private InjectionPoint injectionPoint; } And resolve being the following method: public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) { Set<Bean<?>> beans = beanManager.getBeans(beanClass); for (Bean<?> bean : beans) { if (bean.getBeanClass() == beanClass) { return (Bean<T>) beanManager.resolve(Collections.<Bean<?>>singleton(bean)); } } return (Bean<T>) beanManager.resolve(beans); } As mentioned, while this seems to work, I wonder if it's the best approach. Kind regards, Arjan

8 years, 11 months

4
8
0 / 0

Let's Sept 25th -26th for our F2F meeting

by Antoine Sabot-Durand

Hi all, So the vote closed on modally. We should have talk about the final date in the last meeting, but there was too much on our plate ;). We have a tie between 18th and 25th, but as John can make it for the 25th and he’s probably the farthest one from Paris to come I propose to keep this date. Regards, Antoine

9 years, 5 months

4
4
0 / 0

Final elements for EDR1

by Antoine Sabot-Durand

Hi guys, Unless you send feedback about them here are the final elements I plan to submit to JCP tomorrow at 12:00 CET Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html <https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html> Spec PDF (with a fancy new Look And Feel): https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf <https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf> Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html <https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html> Thanks for your sharp eyes in this ultimate review ;). Antoine

9 years, 6 months

3
3
0 / 0

Canceling meeting today

by Antoine Sabot-Durand

I won’t be available for our meeting today, let’s meet next week. regards, Antoine

9 years, 6 months

1
0
0 / 0

Re: [cdi-dev] Meeting at GeeCon Prague ? (Jozef Hartinger)

by Werner Keil

Antonio/Jozef, Sorry, but the guys in Prague got awfully bad timing for their GeeCon;-O https://jcp.org/en/whatsnew/calendar shows, there's a JCP EC F2F and at least some Spec Leads (like Alex from 375) plan to report to the EC right before JavaOne. Which starts immediately after that (I think there's several JUG, Adopt-a-JSR or DevoXX for Kids events on the 24th, at least it was lasts year) Werner On Tue, Jun 30, 2015 at 9:54 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: EDR1 ready to be released (Antoine Sabot-Durand) > 2. [JBoss JIRA] (CDI-499) Firing events asynchronously > (Antoine Sabot-Durand (JIRA)) > 3. [JBoss JIRA] (CDI-438) Fix type parameters ordering in > ProcessProducerMethod and ProcessProducerField events > (Antoine Sabot-Durand (JIRA)) > 4. Final elements for EDR1 (Antoine Sabot-Durand) > 5. Re: Meeting at GeeCon Prague ? (Jozef Hartinger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 29 Jun 2015 19:43:41 +0000 > From: Antoine Sabot-Durand <antoine(a)sabot-durand.net> > Subject: Re: [cdi-dev] EDR1 ready to be released > To: Mark Struberg <struberg(a)yahoo.de>, "jharting(a)redhat.com" > <jharting(a)redhat.com> > Cc: cdi-dev <cdi-dev(a)lists.jboss.org> > Message-ID: > <CABu-YBRuYcFzJWfuTia2e4cXybFWq= > 5HcNf4zm8JD+tokjJF4w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > > Please correct me if I got this wrong, you like to have a org.boss.weld > > package in the EDR wording? > > > > You're wrong. Nobody's proposed such a thing. But to be sure, you might > want to re-read carefully the spec (nice trick to have another review on > the spec split ;) ). > > More seriously, the spec mention @Priority from commons annotation and it > will stay like that, because it's the target. Wether we keep it in weld or > move it in an experimental package in the spec, this content will not > change. > I'll write a blog post explaining why user can't use the official @Priority > yet and what package to use in the meantime. > I said I find more consistent to have it in Weld experimental, because we > said last week that we didn't want to put temp feature in the spec & API. > > > > In that case a strict -1 for any org.jboss.weld package in the official > > spec EDR! > > That?s a total no-go and is legally not possible as you would force ALL > > implementors to break trademark laws. > > This would also probably (in extremis) diminish the Weld trademark? So > > this is something I guess JBoss would like to prevent as well? > > > > LieGrue, > > strub > > > > > Am 29.06.2015 um 12:44 schrieb Jozef Hartinger <jharting(a)redhat.com>: > > > > > > Hi Antoine, > > > > > > I dislike inventing temporary behavior. For @Priority there seems to be > > consensus about the observer ordering behavior already. We just need a > way > > to enable it until the annotations spec is updated. Weld experimental > > package will work fine. > > > > > > Jozef > > > > > > On 06/29/2015 12:19 PM, Antoine Sabot-Durand wrote: > > >> Hi Jozef, > > >> > > >> I thought you didn't like to have temp stuff in the spec, so fr me it > > was obvious that we should use the weld experimental package. > > >> Any thoughts? > > >> > > >> Antoine > > >> Le lun. 29 juin 2015 ? 11:38, Jozef Hartinger <jharting(a)redhat.com> a > > ?crit : > > >> How do we deal with the lack of parameter-level @Priority in the > > meantime? > > >> > > >> > > >> On 06/25/2015 11:19 AM, Antoine Sabot-Durand wrote: > > >>> Hi guys, > > >>> > > >>> The branch 2.0-EDR1 is ready for release. > > >>> > > >>> Beyond the source, you can check javadoc here: > > >>> https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html > > >>> > > >>> And spec here: > > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html > > >>> > > >>> Or PDF version: > > >>> https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf > > >>> > > >>> I have still some work on introduction (major changes, etc?) and on > > copyright in source files and intend to start release process (three the > > JCP) tomorrow. > > >>> > > >>> 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. > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/4766954d/at... > > ------------------------------ > > Message: 2 > Date: Mon, 29 Jun 2015 15:52:05 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org> > Subject: [cdi-dev] [JBoss JIRA] (CDI-499) Firing events asynchronously > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12561330.1421835166000.90174.1435607525116(a)Atlassian.JIRA> > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... > ] > > Antoine Sabot-Durand reassigned CDI-499: > ---------------------------------------- > > Assignee: Antoine Sabot-Durand > Fix Version/s: 2.0-EDR1 > (was: 2.0 (discussion)) > Resolution: Done > > > > Firing events asynchronously > > ----------------------------- > > > > Key: CDI-499 > > URL: https://issues.jboss.org/browse/CDI-499 > > Project: CDI Specification Issues > > Issue Type: Feature Request > > Components: Events > > Affects Versions: 1.2.Final > > Reporter: Antoine Sabot-Durand > > Assignee: Antoine Sabot-Durand > > Fix For: 2.0-EDR1 > > > > > > We should allow a way to fire event asynchronously. This mechanism > should leverage new async API in JDK8 especially the {{CompletionStage}} > interface. > > Our proposal is: > > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}} > > Signature of the method on {{Event<T>}} would be > > {code:java} > > <U extends T> CompletionStage<U> fireAsync(U event); > > {code} > > Signature on {{BeanManager}} would be > > {code:java} > > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers) > > {code} > > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}} > > For backward compatibility reason the possibility to invoke an observer > asynchronously should be let to the observer (legacy observers should be > called synchronously). We propose to add the boolean {{asyncSupported()}} > member with the {{false}} default value to support this backward > compatibility aspect. > > So to be notified asynchronously an observer should have > {{asyncSupported}} member to true. otherwise it will be called > synchronously. > > h2. 3. Observer bound to a transaction phase > > these observer will be invoked in the right transaction phase but > asynchronously > > h2. 4. Event Ordering > > Should we decide to add events ordering in CDI 2.0, the order will be > keep in asynchronous observer notification. If there are a mix of > synchronous and asynchronous observer, asynchronous will be called first in > order, then synchronous in their order (async has priority on sync). > > h2. 5. Event state (payload mutability) > > We'll keep payload mutability with async events (but should explicitly > specify it). That means that we should guarantee the event state > consistency between observers and in case of ordered observers the fact > that observer N+1 get the event state at the end of observer N. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 3 > Date: Mon, 29 Jun 2015 15:57:02 -0400 (EDT) > From: "Antoine Sabot-Durand (JIRA)" <issues(a)jboss.org> > Subject: [cdi-dev] [JBoss JIRA] (CDI-438) Fix type parameters ordering > in ProcessProducerMethod and ProcessProducerField events > To: cdi-dev(a)lists.jboss.org > Message-ID: > <JIRA.12540105.1399467093000.90177.1435607822369(a)Atlassian.JIRA> > Content-Type: text/plain; charset=UTF-8 > > > [ > https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... > ] > > Antoine Sabot-Durand resolved CDI-438. > -------------------------------------- > Fix Version/s: 2.0-EDR1 > (was: 2.0 (discussion)) > Resolution: Done > > > > Fix type parameters ordering in ProcessProducerMethod and > ProcessProducerField events > > > ------------------------------------------------------------------------------------- > > > > Key: CDI-438 > > URL: https://issues.jboss.org/browse/CDI-438 > > Project: CDI Specification Issues > > Issue Type: Bug > > Affects Versions: 1.2.Final > > Reporter: Martin Kouba > > Assignee: Antoine Sabot-Durand > > Fix For: 2.0-EDR1 > > > > > > Since CDI 1.0 there is an inconsistency in the description of > {{ProcessProducerMethod}} event... > > The text: > > {quote} > > For a producer method with method *return type X* of a bean with *bean > class T*, the container must raise an event of type > ProcessProducerMethod<T, X>. > > {quote} > > API: > > {code:java} > > /** > > * @param <T> The return type of the producer method > > * @param <X> The class of the bean declaring the producer method > > */ > > public interface ProcessProducerMethod<T, X> extends ProcessBean<X> { > > } > > {code} > > The same applies to {{ProcessProducerField}}. > > TCK and RI (Weld) follow the API. As one of the consequences an > {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an > observer with the event parameter {{ProcessBean<Foo>}} - which is required > by the spec but does not make sense at the same time. > > It's obvious that JCP compatibility rules required to keep the wrong > ordering for CDI 1.x (see also the comments in > {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this > should be fixed in CDI 2.0. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) > > > ------------------------------ > > Message: 4 > Date: Mon, 29 Jun 2015 23:02:59 +0200 > From: Antoine Sabot-Durand <antoine(a)sabot-durand.net> > Subject: [cdi-dev] Final elements for EDR1 > To: cdi-dev <cdi-dev(a)lists.jboss.org> > Message-ID: <AFE596FC-6B3E-4050-A5B1-B65F17FD5349(a)sabot-durand.net> > Content-Type: text/plain; charset="us-ascii" > > Hi guys, > > > Unless you send feedback about them here are the final elements I plan to > submit to JCP tomorrow at 12:00 CET > > Spec HTML: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html < > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html> > Spec PDF (with a fancy new Look And Feel): > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf < > https://dl.dropboxusercontent.com/u/2898173/cdi-spec.pdf> > Javadoc: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html < > https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html> > > Thanks for your sharp eyes in this ultimate review ;). > > Antoine > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/at... > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 495 bytes > Desc: Message signed with OpenPGP using GPGMail > Url : > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150629/b18dcddc/at... > > ------------------------------ > > Message: 5 > Date: Tue, 30 Jun 2015 09:54:17 +0200 > From: Jozef Hartinger <jharting(a)redhat.com> > Subject: Re: [cdi-dev] Meeting at GeeCon Prague ? > To: Antonio Goncalves <antonio.goncalves(a)gmail.com>, cdi-dev > <cdi-dev(a)lists.jboss.org> > Message-ID: <55924B29.2020100(a)redhat.com> > Content-Type: text/plain; charset="windows-1252" > > Hi Antonio, > > good idea. I will probably be there. > > Jozef > > On 06/29/2015 03:43 PM, Antonio Goncalves wrote: > > Hi guys, > > > > Don't know if some of you will be at GeeCon Prague in October > > (22nd//23rd of October). If yes, we could maybe organize a meeting. > > And I know that some of the Jersey team is also based in Prague. It > > would be great to have the JAX-RS and CDI team talking about possible > > improvments. > > > > WDYT ? > > > > -- > > Antonio Goncalves > > Software architect, Java Champion and Pluralsight author > > > > Web site <http://www.antoniogoncalves.org> | Twitter > > <http://twitter.com/agoncal> | LinkedIn > > <http://www.linkedin.com/in/agoncal> | Pluralsight > > <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | > > Paris JUG <http://www.parisjug.org> | Devoxx France < > http://www.devoxx.fr> > > > > > > _______________________________________________ > > 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. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/cdi-dev/attachments/20150630/9ad55611/at... > > ------------------------------ > > _______________________________________________ > 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 55, Issue 45 > *************************************** >

9 years, 6 months

1
0
0 / 0

Meeting at GeeCon Prague ?

by Antonio Goncalves

Hi guys, Don't know if some of you will be at GeeCon Prague in October (22nd//23rd of October). If yes, we could maybe organize a meeting. And I know that some of the Jersey team is also based in Prague. It would be great to have the JAX-RS and CDI team talking about possible improvments. WDYT ? -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

9 years, 6 months

2
1
0 / 0

[JBoss JIRA] (CDI-438) Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-438?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-438. -------------------------------------- Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) Resolution: Done > Fix type parameters ordering in ProcessProducerMethod and ProcessProducerField events > ------------------------------------------------------------------------------------- > > Key: CDI-438 > URL: https://issues.jboss.org/browse/CDI-438 > Project: CDI Specification Issues > Issue Type: Bug > Affects Versions: 1.2.Final > Reporter: Martin Kouba > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > Since CDI 1.0 there is an inconsistency in the description of {{ProcessProducerMethod}} event... > The text: > {quote} > For a producer method with method *return type X* of a bean with *bean class T*, the container must raise an event of type ProcessProducerMethod<T, X>. > {quote} > API: > {code:java} > /** > * @param <T> The return type of the producer method > * @param <X> The class of the bean declaring the producer method > */ > public interface ProcessProducerMethod<T, X> extends ProcessBean<X> { > } > {code} > The same applies to {{ProcessProducerField}}. > TCK and RI (Weld) follow the API. As one of the consequences an {{ProcessProducerMethod<Foo,Producer>}} event is not delivered to an observer with the event parameter {{ProcessBean<Foo>}} - which is required by the spec but does not make sense at the same time. > It's obvious that JCP compatibility rules required to keep the wrong ordering for CDI 1.x (see also the comments in {{javax.enterprise.inject.spi.ProcessProducerMethod}}). I believe this should be fixed in CDI 2.0. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-499) Firing events asynchronously

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-499?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand reassigned CDI-499: ---------------------------------------- Assignee: Antoine Sabot-Durand Fix Version/s: 2.0-EDR1 (was: 2.0 (discussion)) Resolution: Done > Firing events asynchronously > ----------------------------- > > Key: CDI-499 > URL: https://issues.jboss.org/browse/CDI-499 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > We should allow a way to fire event asynchronously. This mechanism should leverage new async API in JDK8 especially the {{CompletionStage}} interface. > Our proposal is: > h2. 1. Add {{fireAsync()}} method to {{Event}} and {{BeanManager}} > Signature of the method on {{Event<T>}} would be > {code:java} > <U extends T> CompletionStage<U> fireAsync(U event); > {code} > Signature on {{BeanManager}} would be > {code:java} > <T> CompletionStage<T> fireAsyncEvent(T event, Annotation... qualifiers) > {code} > h2. 2. Add an {{asyncSupported()}} member to {{@Observes}} > For backward compatibility reason the possibility to invoke an observer asynchronously should be let to the observer (legacy observers should be called synchronously). We propose to add the boolean {{asyncSupported()}} member with the {{false}} default value to support this backward compatibility aspect. > So to be notified asynchronously an observer should have {{asyncSupported}} member to true. otherwise it will be called synchronously. > h2. 3. Observer bound to a transaction phase > these observer will be invoked in the right transaction phase but asynchronously > h2. 4. Event Ordering > Should we decide to add events ordering in CDI 2.0, the order will be keep in asynchronous observer notification. If there are a mix of synchronous and asynchronous observer, asynchronous will be called first in order, then synchronous in their order (async has priority on sync). > h2. 5. Event state (payload mutability) > We'll keep payload mutability with async events (but should explicitly specify it). That means that we should guarantee the event state consistency between observers and in case of ordered observers the fact that observer N+1 get the event state at the end of observer N. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

EDR1 ready to be released

by Antoine Sabot-Durand

Hi guys, The branch 2.0-EDR1 is ready for release. Beyond the source, you can check javadoc here: https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html <https://dl.dropboxusercontent.com/u/2898173/EDR1-Doc/index.html> And spec here: https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html <https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html> Or PDF version: https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf <https://dl.dropboxusercontent.com/u/2898173/cdi-2.0-EDR1.pdf> I have still some work on introduction (major changes, etc…) and on copyright in source files and intend to start release process (three the JCP) tomorrow. Antoine

9 years, 6 months

4
13
0 / 0

[JBoss JIRA] (CDI-501) Firing and consuming events should take place in the same thread

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-501?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand resolved CDI-501. -------------------------------------- Assignee: Antoine Sabot-Durand Resolution: Done Was stated during CDI-499 writing > Firing and consuming events should take place in the same thread > ---------------------------------------------------------------- > > Key: CDI-501 > URL: https://issues.jboss.org/browse/CDI-501 > Project: CDI Specification Issues > Issue Type: Clarification > Components: Events > Affects Versions: 1.2.Final > Reporter: José Paumard > Assignee: Antoine Sabot-Durand > Fix For: 2.0-EDR1 > > > An event can be fired with a call to event.fireEvent(payload). CDI then calls all the observers for that event with the given payload. > All the implementations call the annotated methods of the observers in the same thread as the one where the call to fireEvent() was made. In some cases the payload object is mutable, and the observers leverage that property to change its state. > The issue is the following : > - the payload object is not specified, it can then be mutable, non-synchronized etc... > - it is not stated that the firing of the event and the consuming of the payload should occur in the same thread. > So one could build an implementation where the consuming of the event occurs in different threads than the one where the fireEvent() was called. If the payload is mutated in the observer methods then visibility issues due to race conditions can arise. > Side note : most of the time it is also assumed that the fireEvent() method returns when all the observers have been called and returned. This point is not specified. We can assume that other issues could arise when it is not the case. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev June 2015