Hi,,
On Thu, Feb 12, 2015 at 9:11 PM, Mark Struberg <struberg_at_yahoo.de> wrote:
> 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?
Yes, that's perhaps an unfortunate consequence. In JSF 2.2
faces-config.xml nor web.xml is technically needed (but read below).
> 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.
That's not entirely correct. JSF should not be activated in such
projects. There's a ServletContainerInitializer that will check for
any of the following types (annotations and classes) being
present/used in the application:
ManagedBean.class,
FacesComponent.class,
FacesValidator.class,
FacesConverter.class,
FacesBehaviorRenderer.class,
ResourceDependency.class,
ResourceDependencies.class,
ListenerFor.class,
ListenersFor.class,
UIComponent.class,
Validator.class,
Converter.class,
Renderer.class
OR whether there's a WEB-INF/faces-config.xml, which just like
beans.xml can be empty. Only if any of these two conditions is true
will the FacesServlet be mapped to *.jsf, *.faces and /faces/*.
So JSF should not have been activated for those pure JSP/Servlets
projects that you mentioned.
In practice, since many JSF applications use @Named instead of
@ManagedBean and BeanValidation instead of native JSF validators, and
certainly not every application uses converters (especially when
starting), an empty faces-config.xml is typically used these days to
activate JSF.
Kind regards,
Arjan Tijms
>
>
> 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
>>>>>
>>>>>
>>
>>