Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [faces-dev] Deprecate @FacesConfig

Hi,

The faces-config.xml is already a valid marker, though, if I'm not mistaken we had the spec bug a long time ago where it couldn't be explicitly empty (like beans.xml). 

The spec currently says:

"Adds mappings *.xhtml, /faces, *.jsf, and *.faces for the FacesServlet (if it hasn't already been mapped) if the following conditions are met:
  • The Set of classes passed to this initializer is not empty, or
  • /WEB-INF/faces-config.xml exists, or
  • A CDI enabled bean with qualifier FacesConfig can be obtained"
I've to check whether we still have that bug, otherwise we could clarify the spec saying:

"/WEB-INF/faces-config.xml exists (may be empty) , or"

We also discussed the idea back then to add other common options to @FacesConfig. The advantage is that users can more easily autocomplete them compared to general parameters in web.xml.

Kind regards,
Arjan




On Mon, Jan 18, 2021 at 4:19 PM Thomas Andraschko <tandraschko@xxxxxxxxxx> wrote:
If it should be for auto-faces-servlet-mapping-marker only, then we should really talk about it if it's the best way.
We could also name it then "@AutoRegisterFacesServlet" or take the faces-config.xml inside the WAR as marker, which probably already exists in 90% of the times.


Am Mo., 18. Jan. 2021 um 16:08 Uhr schrieb arjan tijms <arjan.tijms@xxxxxxxxx>:
Hi,

The latest and greatest should indeed always be used. That weird simulation is just odd, but didn't we already agree to remove the "fake faces 2.2 mode"?

@FacesConfig's main purpose is to add the Faces servlet mapping automatically. 

Before @ManagedBean would be used for that, but we've deprecated it, and are going to remove it. Some of the other Faces annotations can still be used for that, but most of them are not always present in a Faces application.

So +1 for removing the fake version and its semantics (always use latest and greatest
-1 for removing @FacesConfig itself, as it's a marker

Kind regards,
Arjan







On Mon, Jan 18, 2021 at 4:00 PM Thomas Andraschko <tandraschko@xxxxxxxxxx> wrote:
TBH I didn't understand why you introduced it anyway.
As you said, the default should be the latest and greatest always.
You can never simulate 100% of JSF2.0 in e.g. JSF2.3 container, if you configure @FacesConfig(2.0);

I would also get rid of it an rely on a specific feature configuration like javax.faces.ENABLE_CDI_RESOLVER_CHAIN.




Am Mo., 18. Jan. 2021 um 15:44 Uhr schrieb Manfred Riem <m_riem@xxxxxxxxxxx>:

Hi all,

 

Let’s deprecate @FacesConfig and make the default always the latest and greatest of Faces!

 

Agreed?

 

Thanks!

 

Kind regards,

Manfred Riem

 

_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
_______________________________________________
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev

Back to the top