Note, there's only actually one PerThread service here which is
RequestGlobals.
All other services (Request, Response, ApplicationStateManager) point to
this service. So, if you initialize RequestGlobals your async worker should
be OK.
You might be able to do the Following.
public class SomePage
Both the Environment and the Request are PerThread services. As I said, the
services themselves are singletons / proxies. It doesn't matter how you
pass around the services, they won't work on a non-request thread. The
AlertManager points to the ApplicationStateManager which manages the
session. Th
Hi Lance,
Yes what you say is true, however to make the AlertManager compatible
with asynchronous usage (ie the request/response is gone but the session
is still a valid context) the code could simply change from:
if (request.isXHR())
(and removing the Request field)
to
R
The Request and Response are PerThread services meaning the service is
actually proxy which passes through to a PerThreadValue. This PerThread
value will be null on a non-request thread.
There's a few approaches to work around this including:
1. Pass values from the request thread to the worker on
Hi, i'm not sure if this is worth logging as a Jira or if i've missed
the point.. please advise.
I'm adding an alert via alertManager in an inner thread.
void onSomething()
{
final AlertManager fAlerts = alerts;
new Thread()
{
public void run()
{
do
