From a backward compat pov this is imo better. But that basically mandates faces-config.xml again if you like to switch to the new behaviour, right?
To be honest I didn't like the auto-activation of JSF via ServletContextInitializer anyway. Because it also did activate JSF for projects where I purely had JSP or just Servlets.
So I'm not a fan of blindly trashing all the XML config. Those config giles have some good parts also.
LieGrue,
strub
On Thursday, 12 February 2015, 20:17, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>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
>>>>
>>>>
>
>