faces
faces copied to clipboard
jakartaee
Introduce annotation/class based configuration
In JSF 2.2 the way to automatically enable JSF in a project is having either a class on the class path annotated with one of the JSF native annotations, or having a /WEB-INF/faces-config.xml file present.
With the world moving to CDI, the JSF native annotations (specifically @MangedBean) are not so much used anymore. This way to enable JSF is therefor not longer practical.
A faces-config.xml file is still a simple way, if it wasn't for the fact that officially it can't be just an empty file like CDI's bean.xml. Looking up the right schema for trivial applications is a bit of a hassle.
Therefor it might be worth looking into a JSF annotation that is specifically intended to enable JSF.
E.g.
@FacesConfig
public class JustAClass {
}
In the simplest version this will just activate JSF like @ManagedBean does, but without the side effect of also creating a (potentially unused) managed bean.
One step further may be to add some configuration options, potentially the annotation variant of the various web.xml settings.
E.g.
@FacesConfig(
stateSavingMethod = "server"
)
Or a new option, to indicate the JSF version:
@FacesConfig(
version = "2.3" // enables all JSF 2.3 features )
@FacesConfig(
version = "2.2" // behaves as much as possible as 2.2 did )
This mechanism can also be used for simple configuration sets. Namely, if the class on which @FacesConfig appears is a CDI bean, CDI alternatives can be used to switch configuration.
Going another step further the class could (optionally) implement methods that return config programmatically.
E.g.
@FacesConfig
public class MyConfig {
public String getStateSavingMethod() {
return ... ? "server" : "client";
}
}
But that really is an optional proposal. The main proposal is just having the annotation.
Note that the class on which the annotation is put doesn't matter that much; it only has to be on the class path such that the runtime code (e.g. via a CDI extension) can pick it up.
Affected Versions
[2.3]
- Issue Imported From: https://github.com/javaee/javaserverfaces-spec/issues/1416
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: @edburns
@glassfishrobot Commented This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1416
PR: https://github.com/eclipse-ee4j/mojarra/pull/5344
Faces context params have now been mapped to @FacesConfig attributes.
We can now use
@FacesConfig(
projectStage = Development,
automaticExtensionlessMapping = true,
interpretEmptyStringSubmittedValuesAsNull = true
)
public class Config {
}
And we can if necessary programmatically retrieve them via new API as well:
boolean disableDefaultBeanValidator = ContextParam.DISABLE_DEFAULT_BEAN_VALIDATOR.getValue(facesContext);
String faceletsViewMappings = ContextParam.FACELETS_VIEW_MAPPINGS.getValue(facesContext);
int faceletsRefreshPeriod = ContextParam.FACELETS_REFRESH_PERIOD.getValue(facesContext);
String[] faceletsViewMappings = ContextParam.FACELETS_VIEW_MAPPINGS.getValue(facesContext);
It will first check for any context param value and then for any @FacesConfig value and then fall back to its spec default.
Mojarra impl has been updated to utilize these.
cc: @arjantijms @mnriem @tandraschko
