Hi,
On Friday, November 28, 2014, Stuart Douglas <stuart.w.douglas_at_gmail.com>
wrote:
> * It's not as user friendly and obvious for new users
>>
>
> Does this really matter? I don't think this is a really common use case.
>
I haven't really surveyed this topic, but from personal experience I know
that I've seen it in pretty much every Java EE application I've been
involved with. The concept of stateless (almost always meaning no-sessions)
comes up really often in discussion about web frameworks. And the question
really did came up more than once on SO.
>
>
>> * HttpSessionListener is great for logging the stack, but can't
>> replace or veto the session about to be created
>
> * Wrapping HttpServletRequest in a filter can replace the session, but
>> sessions can be created before the first filter hits, e.g. by a
>> (JASPIC) auth module.
>>
>
> If you have an auth module that requires a session then is seems likely
> that disabling sessions will break your authentication, replacing one
> problem with another.
>
Not necessarily. Just had a case two weeks back were an auth context
(concept in JASPIC that manages a stack of modules) stored the currently
chosen stack in the session, but there was only one stack. If it saves this
to a temporary session nothing would break.
Another example is that modules could use the global switch to save their
state in a cookie instead, of if they can't/won't do this, throw an
exception so that it's clear the module in question isn't compatible with
session/stateless operation.
One step further, with such a switch in place a next version of the JASPIC
spec (or the Security API) could even let modules declare this explicitly,
and then the container can check this during startup. Basically like CDI is
doing now with Passivating scopes and checking whether a bean is
serializable.
For the 3rd party library case (e.g. the JSF case you mentioned) this
> approach will work fine.
>
>
>> * From a user wrapping the HttpServletRequest other specs can't infer
>> the user's intention; in JSF we can't process this to switch to save
>> state on client.
>>
>
> If a user wants client side state saving they can just explicitly specify
> it.
>
They can, and then also set a similar setting for MVC (hope they will have
one), and then check all auth modules used and set settings on them too,
and then check additional (web) libraries to see if they have their own
settings for this, and then try to prevent JSP pages from creating a
session in a custom way, etc.
It's not that it all can't be done today, but having a clear declaration
stating that the app doesn't want sessions with one switch sure would make
things simpler and would open up a range of new possibilities for automatic
validation of deployments.
Kind regards,
Arjan
>
> I am -1 on this at the moment, it seems like a niece use case that there
> are already ways to solve.
>
> Stuart
>
>
>>
>> > I guess I am -0 on this at the moment.
>>
>> I'm personally +1 on the switch, but could also see a somewhat lower
>> level facility where an HttpSessionListener (or other listener) has
>> the ability to provide a replacement HttpSession (or null even). That
>> could pretty much also solve the first 3 points listed above.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>> >
>> > Mark
>> >
>>
>