From BENJAMIC at uk.ibm.com  Tue Jul 17 12:30:54 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Tue, 17 Jul 2018 17:30:54 +0100
Subject: [weld-dev] Should EventImpl.fireAsync use ExecutorServices from the
	ServiceRegistry
Message-ID: <OF1EB2CDC6.17F23672-ON002582CD.0052AFBD-802582CD.005AB874@notes.na.collabserv.com>

Hello

I have a customer with the following 

        @Inject

        Event<Message> event;

        @Resource
        ManagedExecutorService threadPool;

        public void fireAsyncEvent() {

                System.out.println("Sending Async-Message via CDI");

                event.fireAsync(new Message("Hello"));

        }

        public void fireAsyncEvent_2() {
                event.fireAsync(new Message("Hello"), 
NotificationOptions.ofExecutor(threadPool));
        }

fireAsyncEvent() eventually results in an NPE when a JSF class attempts 
tries to call CDI.current() fireAsyncEvent_2() works correctly. I was 
hoping that it would be possible to fix fireAsyncEvent to remove the 
dependency on passing in an executor service every time it is used. 

We currently set an executor service into the weld service registry, and I 
was wondering if org.jboss.weld.event.EventImpl fetch the  executor 
service from the service registry. Either only when fireAsync is called 
without any NotificationOptions, or perhaps more aggressively and set the 
default executor service if NotificationOptions are provided but do not 
explicitly contain an executor service (The javadoc is unclear, but I 
believe calling ofExecutor() provides this functionality). 

Before going further with this I wanted to ask for a quick sanity check. 
Is this fix plausible? 

Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180717/43bb161f/attachment.html 

From mkouba at redhat.com  Wed Jul 18 03:17:59 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 18 Jul 2018 09:17:59 +0200
Subject: [weld-dev] Should EventImpl.fireAsync use ExecutorServices from
 the ServiceRegistry
In-Reply-To: <OF1EB2CDC6.17F23672-ON002582CD.0052AFBD-802582CD.005AB874@notes.na.collabserv.com>
References: <OF1EB2CDC6.17F23672-ON002582CD.0052AFBD-802582CD.005AB874@notes.na.collabserv.com>
Message-ID: <30ec7e5a-bbcd-0c89-c498-22b314b2f6e7@redhat.com>

Hi Benjamin,

If no Executor is provided - either fireAsync(U event) or no executor 
set to the notification options - Weld uses the Executor returned from 
org.jboss.weld.manager.api.ExecutorServices#getTaskExecutor() or 
ForkJoinPool#commonPool() if no ExecutorServices is registered. In other 
words, it's up to the integrator which Executor is used.

And yes, Event#fireAsync(U, NotificationOptions) javadoc is outdated - 
in the first versions it was only possible to pass an Executor.

What does the NPE look like?

Thanks,

Martin

Dne 17.7.2018 v 18:30 Benjamin Confino napsal(a):
> Hello
> 
> I have a customer with the following
> 
>  ? ? ? ?@Inject
>  ? ? ? ? Event<Message> event;
> 
>  ? ? ? ? @Resource
>  ? ? ? ? ManagedExecutorService threadPool;
> 
>  ? ? ? ?public void fireAsyncEvent() {
>  ? ? ? System.out.println("Sending Async-Message via CDI");
>  ? ? ? event.fireAsync(new Message("Hello"));
>  ? ? ? ? }
> 
>  ? ? ? ? public void fireAsyncEvent_2() {
>  ? ? ? event.fireAsync(new Message("Hello"), 
> NotificationOptions.ofExecutor(threadPool));
>  ? ? ? ? }
> 
> fireAsyncEvent() eventually results in an NPE when a JSF class attempts 
> tries to call CDI.current() fireAsyncEvent_2() works correctly. I was 
> hoping that it would be possible to fix fireAsyncEvent to remove the 
> dependency on passing in an executor service every time it is used.
> 
> We currently set an executor service into the weld service registry, and 
> I was wondering if org.jboss.weld.event.EventImpl fetch the ?executor 
> service from the service registry. Either only when fireAsync is called 
> without any NotificationOptions, or perhaps more aggressively and set 
> the default executor service if NotificationOptions are provided but do 
> not explicitly contain an executor service (The javadoc is unclear, but 
> I believe calling ofExecutor() provides this functionality).
> 
> Before going further with this I wanted to ask for a quick sanity check. 
> Is this fix plausible?
> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Wed Jul 18 16:42:50 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Wed, 18 Jul 2018 21:42:50 +0100
Subject: [weld-dev] Should EventImpl.fireAsync use ExecutorServices from
 the ServiceRegistry
In-Reply-To: <30ec7e5a-bbcd-0c89-c498-22b314b2f6e7@redhat.com>
References: <OF1EB2CDC6.17F23672-ON002582CD.0052AFBD-802582CD.005AB874@notes.na.collabserv.com>
	<30ec7e5a-bbcd-0c89-c498-22b314b2f6e7@redhat.com>
Message-ID: <OF6B224EBD.FC7CD77E-ON002582CE.0070FC4A-802582CE.0071C916@notes.na.collabserv.com>

Hi Martin. 

My mistake. I thought the EventImpl was ignoring 
ExecutorServices#getTaskExecutor() but after reading your email I checked 
again and found it later down the stack, and upon further investigation 
the Executor we're providing doesn't handle what I was told it would, 
which means it can be fixed. Thanks for your help. 

P.S. The NPE is CDI.current() returning null, then a method is called on 
that null. It's the result of some ThreadLocals not being set inside our 
code.



From:   Martin Kouba <mkouba at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>, weld-dev at lists.jboss.org
Cc:     Tom Evans <TEVANS at uk.ibm.com>, Emily Jiang <EMIJIANG at uk.ibm.com>
Date:   18/07/2018 08:18
Subject:        Re: [weld-dev] Should EventImpl.fireAsync use 
ExecutorServices from the ServiceRegistry



Hi Benjamin,

If no Executor is provided - either fireAsync(U event) or no executor 
set to the notification options - Weld uses the Executor returned from 
org.jboss.weld.manager.api.ExecutorServices#getTaskExecutor() or 
ForkJoinPool#commonPool() if no ExecutorServices is registered. In other 
words, it's up to the integrator which Executor is used.

And yes, Event#fireAsync(U, NotificationOptions) javadoc is outdated - 
in the first versions it was only possible to pass an Executor.

What does the NPE look like?

Thanks,

Martin

Dne 17.7.2018 v 18:30 Benjamin Confino napsal(a):
> Hello
> 
> I have a customer with the following
> 
>         @Inject
>          Event<Message> event;
> 
>          @Resource
>          ManagedExecutorService threadPool;
> 
>         public void fireAsyncEvent() {
>        System.out.println("Sending Async-Message via CDI");
>        event.fireAsync(new Message("Hello"));
>          }
> 
>          public void fireAsyncEvent_2() {
>        event.fireAsync(new Message("Hello"), 
> NotificationOptions.ofExecutor(threadPool));
>          }
> 
> fireAsyncEvent() eventually results in an NPE when a JSF class attempts 
> tries to call CDI.current() fireAsyncEvent_2() works correctly. I was 
> hoping that it would be possible to fix fireAsyncEvent to remove the 
> dependency on passing in an executor service every time it is used.
> 
> We currently set an executor service into the weld service registry, and 

> I was wondering if org.jboss.weld.event.EventImpl fetch the  executor 
> service from the service registry. Either only when fireAsync is called 
> without any NotificationOptions, or perhaps more aggressively and set 
> the default executor service if NotificationOptions are provided but do 
> not explicitly contain an executor service (The javadoc is unclear, but 
> I believe calling ofExecutor() provides this functionality).
> 
> Before going further with this I wanted to ask for a quick sanity check. 

> Is this fix plausible?
> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> 
https://lists.jboss.org/mailman/listinfo/weld-dev

> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180718/dfc6235d/attachment.html 

From ooo_saturn7 at mail.ru  Sat Jul 21 04:54:58 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Sat, 21 Jul 2018 11:54:58 +0300
Subject: [weld-dev] =?utf-8?q?How_to_use_Weld_servlet_Env_with_Grizzly=3F?=
Message-ID: <1532163298.408541522@f273.i.mail.ru>

Hi all

I already wrote to this mailing list but didn't get any answer, so this is my last attempt to get any help.

I want to use Weld servlet Env with Grizzly and found out that in order to control instance 
creating in Grizzly it is necessary to override some methods in WebappContext. So I created these two classes:
https://github.com/PavelKastornyy/weld-core/tree/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/grizzly
? 
However, objects are not injected in servlets as expected. Could anyone comment my code?

-- 
Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180721/caf025ed/attachment-0001.html 

From manovotn at redhat.com  Thu Jul 26 06:35:38 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Thu, 26 Jul 2018 06:35:38 -0400 (EDT)
Subject: [weld-dev] Weld 3.0.5.Final released
In-Reply-To: <923766063.54420140.1532598555421.JavaMail.zimbra@redhat.com>
Message-ID: <593977067.54431026.1532601338354.JavaMail.zimbra@redhat.com>

Hello,

Weld 3.0.5.Final was released along with Weld API 3.0.SP4 (and CDI API 2.0.SP1).
For more information, check our release notes -> http://weld.cdi-spec.org/news/2018/07/26/weld-305Final/

Matej