On Thu Nov 27 2014 at 10:23:35 PM arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Thu, Nov 27, 2014 at 11:24 AM, Mark Thomas <markt_at_apache.org> wrote:
> > 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.
>
> Yes, an HttpSessionListener in combination with wrapping the request
> gets you a long way, and this is indeed what we have been using. But
> it has a few issues, some small, some big:
>
> * 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.
> * 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.
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.
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
> >
>