> Servlet filter to set up DWR ThreadLocals:
> Aren't you aiming to do all work in the "page" request, ie the root request loading the page? Then no extra DWR info is added to the request, so we can't set up our ThreadLocals. We can only do this for requests sent by the DWR client layer.
You are correct that currently DWR has no interaction with the PAGE request. What I am proposing is that a subset of PAGE requests are mapped to the filter and do have DWR thread locals associated with them.
> Reuse existing ScriptSession if exists:
> As we don't have the extra DWR info (the page request doesn't transfer any scriptSessionId), we don't know if there is already a ScriptSession. On the flip side though, if you are using the default ScriptSession model, where a new ScriptSession is created for every page load, then you can be certain that no ScriptSession exists yet and can safely create a new one.
For PAGE requests, the scriptSession will NEVER exist. A scriptSession currently is created when engine.js is included which is after the PAGE request. I am proposing that we could instead do this step a bit earlier in the PAGE request. Currently, when engine.js is included, a scriptSessionId is not passed. engine.js fires off a request to create the scriptSession (and scriptSessionId). Only subsequent DWR requests pass the scriptSessionId.
> Creating a new ScriptSession:
> I guess this could be done like this with the current APIs and without requiring being inside a DWR thread:>
> Container container = ServerContextFactory.get().getContainer();
> ScriptSessionManager ssmgr = container.getBean(ScriptSessionManager.class);
> String myScriptSessionId = ...
> ScriptSession ss = ssmgr.getScriptSession(myScriptSessionId, page, sessionId);
I was thinking that for PAGE requests mapped to the filter, it could be done as if it was a normal DWR request.
> Handing over the scriptSessionId to DWR engine.js in the page:
> If my assumptions above are correct, this is the only part left that needs implementing. You need some way of setting the scriptSessionId before engine.js gets a chance to set up its own, is that right?