On 27/11/2014 08:38, arjan tijms wrote:
> Hi,
>
> On Thu, Nov 27, 2014 at 4:30 AM, Stuart Douglas <sdouglas_at_redhat.com> wrote:
>> I'm still not sure what the actual use case for this is, I assume it is an
>> app with some 3rd party code calls getSession(true)?
>
> We used our own code for this in the past to indeed work around 3rd
> party code. This can be container code as well, for instance in the
> 2.0 timeframe, Mojarra always created sessions automatically to store
> some encoding info.
>
> A global "no sessions switch" can also be used as a development time
> facility to help pinpoint which code is creating sessions and where.
There are other ways to do this (e.g. an HttpSessionListener that logs
the current stack trace). My general preference is not to add to the
Servlet spec when it is already possible to meet the requirement with
the existing API.
That said, I can see the benefits of something that sends a clear
message that the Servlet spec expects all spec features to be
implemented without sessions unless explicitly stated otherwise (I am
thinking again of FORM auth here). Could we do this simply in the spec
document itself?
> As such the facility is not entirely unlike a feature we recently
> introduced in OmniFaces; the NoAutoGeneratedIdViewHandler (
> http://showcase.omnifaces.org/viewhandlers/NoAutoGeneratedIdViewHandler),
> which throws an exception as soon as JSF auto-generates an ID
> somewhere. This is very useful to pinpoint during development and QA
> where components without explicit IDs are used. It's assumed to be
> turned off in production.
This approach can be very useful. We did something similar in Tomcat to
complain about memory leaks and as a result got a whole bunch of issues
in a number of different libraries fixed.
> So the options for such a switch could be:
>
> * Throw exception
> * Create session for 1 request
I guess I am -0 on this at the moment.
Mark