Hi,
On Thursday, February 12, 2015, Shing Wai Chan <shing.wai.chan_at_oracle.com>
wrote:
> When there is no web.xml, by default, it's the latest version.
In JSF we now do it exactly the other way around. Would be great if Java EE
could give some central guidance here.
Kind regards,
Arjan Tijms
> 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
>>>
>>>