Hi,
On Fri, Nov 28, 2014 at 1:14 PM, Martin Grigorov
<martingrigorov_at_yahoo.com> wrote:
> By saving in session I guess you mean HttpSession#setAttribute().
> Then what is the difference between HttpServletRequest#setAttribute() and
> the imaginery temporary session ?
Nothing, they would become equivalent.
> If I want to keep my app sessionless then I'd use HttpSessionListener that
> throws an exception as soon as a session is created. Not just log it.
> This will tell me immediately that I'm taking a wrong path or I'm using not
> optimal (for my use case!) web container/framework/extension.
Indeed, that's a technique used now for that. A new switch would just
add more options.
> By adding a new setting that tells what should be the behavior you'd force
> every container/framework/extension to support both states.
> Why a framework that relies on sessions should be against the spec, assuming
> the new setiing says "stalessless only",
Nothing would be against the spec. If a framework that absolutely
needs sessions sees that the session switch is set to "no", it would
simply not run and tell the user to remove that setting if it wants to
use that framework.
This is IMHO not entirely unlike CDI checking that a bean with a
passivating scope is serializable. If the bean by its design can't be
serializable, it can't use that scope. It's not against the spec, but
it just can't use that scope.
> and another framework that is
> completely stateless by design should care about "stateful" mode ?
I don't get this. There is no mode proposed that asks frameworks to be
stateful. If sessions are allowed (the default) then a completely
stateless framework just works as it always has worked. That it's
allowed to create sessions is something totally different than that it
has to create sessions.
Kind regards,
Arjan Tijms
>
> My 2c.
>
> Cheers
>
>
>
> On Friday, 28 November 2014, 12:58, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>
>
>
> 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
>>
>
>
>