WELD-862 and Seam Cron
by Peter Royle
Hi,
I'm aiming to make a release of Seam Cron available within the next two weeks. Currently there is an outstanding issue (https://issues.jboss.org/browse/WELD-862) which prevents Cron from running properly with Weld. I have been able to carry on developing Cron by testing it against OpenWebBeans, but obviously if we are to release a Seam module it should work against Weld.
It would be nice if WELD-862 could be fixed as soon a possible so that all future versions will work well with Cron.
But more importantly I also probably need to do something special in Cron so that it will work with the version of Weld already deployed in JBoss AS and Glassfish, which will contain the bug. The workaround mentioned in the bug report is to deep copy the InvocationContext. I attempted to do this by serialising and unserialising the InvocationContext but couldn't due to UnserializableExceptions. Does anyone have any advice for me about how I might be able to work around this bug to support existing versions of Weld?
Cheers,
Pete R
2 months
Should EventImpl.fireAsync use ExecutorServices from the ServiceRegistry
by Benjamin Confino
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
7 years, 8 months
