True ... we have also found out that it does not work properly to use Quartz-backed @Asynchronous mail sending as of Seam 2.1.1.CR1.
While waiting for a proper fix it seems to be just fine to home roll
the asynchronicity:
// todo Home rolled asynchronicity. : ( Awaiting fix of JBSEAM-3555. SERVICE.submit(new Runnable() { public void run() { mailer.scheduleSend(Email.this); } });
... where SERVICE is any of all ExecutorServices you might fancy, for instance:
private final static ExecutorService SERVICE = Executors.newSingleThreadExecutor();
Works for us. For now.
How do you handle the context when the mail sending is running on another thread? I tried this concept but I am getting a No application context active
error.
I tried getting the application context in the separate thread using the following:
Lifecycle.beginCall();
Renderer.instance().render(/simple.xhtml
);
Lifecycle.endCall();
When I did this, I was back at square one. Got the initial error message. (ie. Application was not properly initialized at startup)
As per Seam Jira issue id JBSEAM-3555, this will get fixed in 2.1.1.CR2. Not sure when that will be out. In the meantime is there a workaround.
Appreciate if we can come up with a workaround until the problem is fixed. I don't want to use java mail API for asynchronous mail as the seam way is so easy but I guess I might have to do that at least until JBSEAM-3555 is resolved.
If anyone has a workaround, please let me know.