When there is no web.xml, by default, it's the latest version.
In this case, an old app may pick up this version / semantics
unintentionally.
We need to think more carefully if we have a different semantics.
Shing Wai Chan
On 2/12/15, 6:57 AM, Mark Struberg wrote:
>> Problems will occur when the new semantics are at odds with how a
>> container currently behaves. I think this can be addressed with
>> container specific options to restore the old behaviour for those apps
>> that have issues.
> Either that or simply make it depending on the version="4.0" in the web.xml.
>
> (however this and a lot other version depending features are activated by apps which don't like to have web.xml...)
>
> LieGrue,
> strub
>
>
>
>
>
>> On Thursday, 12 February 2015, 13:53, Mark Thomas<markt_at_apache.org> wrote:
>>> On 11/02/2015 06:59, Greg Wilkins wrote:
>>>
>>> On 11 February 2015 at 01:45, Mark Thomas<markt_at_apache.org
>>> <mailto:markt_at_apache.org>> wrote:
>>>
>>> HttpSession.markAsDirty(String attributeName)
>>>
>>>
>>> The problem with just adding a new method is that it essentially leaves
>>> the undefined behaviour of setAttribute as is. If an application was
>>> not calling markAsDirty() then we would not know if that was because it
>>> didn't know about the API or was it written expecting some funky
>> session
>>> that auto detects deep object mutations.
>> I addressed this in a different part of the thread (only on users I
>> think). We make it explicit that:
>>
>> * setAttribute() has an automatic side-effect of calling markAsDirty()
>>
>> * setAttribute() when the value is unchanged (i.e. the object being
>> passed is the same (read == ) as the object mapped to that attribute)
>> is a NO-OP apart from the side-effect of calling markAsDirty()
>>
>>> If we really want to fix this, then perhaps we need modal behaviour:
>>> either we work in the current ill defined API, where applications are
>>> essentially tied to specific session implementations; or we enter a new
>>> mode with precise portable cluster semantics - in which case we we may
>>> as well use an entirely new API - or extension of the existing API.
>>>
>>> To repeat myself in a different way, we could have two session
>>> mechanisms behind the same JSESSIONID tracking. If you call
>>> request.getHttpSession() you get the old ill defined session. If you
>>> call request.getDistributedSession() then you'd get the well defined
>>> cluster session. You could even call both if you wanted to have some
>>> session information held on the node and other in the cluster.
>>>
>>> I think any attempt to slip good semantics under the existing session
>>> API is going to break as many applications as it fixes.
>> Problems will occur when the new semantics are at odds with how a
>> container currently behaves. I think this can be addressed with
>> container specific options to restore the old behaviour for those apps
>> that have issues.
>>
>> I'd rather clarify the current API and add a few container specific
>> options for backwards compatibility than add a whole new API.
>>
>>
>> Mark
>>