Details
Improvement
Open
Major
Description
WADI intercepts requests coming into the web-container and decides at this point whether to run them locally (their session must be owned by the local node) or remotely (their session is owned by someone else). Once a request is in the container (i.e. in app code) it is too late to make this call.
When I was working with Jetty5/TC50, I decided, for portability's sake, to put this fn-ality in the 1st Filter on the FilterStack (Filters are standard Servlet Spec components). However, in getting WADI working on JBoss, I found that they had shipped their Tomcat with an extra Valve (like Filter but proprietary API and runs before Filters) which required access to the HttpSession. This is bad news, since WADI has not yet made up its mind what to do. The solution is that WADI needs to make this decision before any Valve (or in Jetty - Handler) can try to get hold of the session. So WADI needs to be first on the Valve/Handler stack - not on the Filter stack. PROBLEM - because the APIs at this level are proprietary in Jetty5 and TC50 (Jetty6 and TC55 both use ServletRequest/Response, standard interfaces, at this level), this means that we need a way of adapting the proprietary Jetty and TC classes to look like ServletRequest/Response to the rest of WADI, before we can make this move. I am already using a Valve/Handler to do some security stuff, so the infrastructure is already in place. I'm also not sure whether in the case of deciding that the request should be run remotely a Valve/Handler can completely redirect request processing away from the application in Jetty5/TC50 - this needs to be explored...