11:30 a.m.
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
2:17 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
3:42 p.m.
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(a)redhat.com>
To: Benjamin Confino <BENJAMIC(a)uk.ibm.com>, weld-dev(a)lists.jboss.org
Cc: Tom Evans <TEVANS(a)uk.ibm.com>, Emily Jiang <EMIJIANG(a)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):
--
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
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
2350
days inactive
2351
days old
2 comments
2 participants
participants (2)
-
Benjamin Confino -
Martin Kouba