I think it was just not thought about when doing servlet-3.0 because then it was the first version who made web.xml optional. But all that did just work for servlet-3.0 and now there is an implicit backward compat issue for all future versions :(
LieGrue,
strub
> On Thursday, 12 February 2015, 19:37, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
> > 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
>>>
>