In web-enabled environments that also service RPC calls (RMI/RMI-over-JMS/SOAP/REST/etc), the DefaultWebSecurityManager and some of its default components (WebRememberMeManager, WebSubjectFactory, etc) use the following calls:
WebUtils.getRequiredServletRequest() WebUtils.getRequiredServletResponse() The problem here is if an RPC call comes in and the transport layer is _not_ HTTP, there will not be any thread-bound servlet request or response. In these cases, these calls always throw an IllegalStateException. But the scenario is logical in enterprise installations - where the SecurityManager needs to service both web requests and non-web-based RPC calls simultaneously. We definitely should support this cleanly. Question: Should we continue to force the 'required' check? Or is it OK instead to just check to see if the thread-bound objects are null and assume in these cases the call came in on a non-http remoting invocation? I think I prefer not requiring the thread-bound request/response pair and checking for null. It is certainly the least impact on the code base. But this opens up the issue that during test cases, the end-user doesn't need to set up request/response mocks. If they don't set up req/resp mocks, they wouldn't accurately reflect the web-based environment that would exist for them at runtime when using the JSecurityFilter. What do you think?
