Working with context parameters (initialization parameters)

Parameters declared via <context-param> are known as context or initialization parameters. They are declared in web.xml and they are used for initialization purposes at application level, they are NOT specific to JSF. Per example, in a web application you can easily have access to them from a Servlet:

HttpServletRequest request;

// get an initialization parameter by name (<param-name> content)

String param = request.getServletContext().getInitParameter("param_name");

or

// in a Servlet

public void init(ServletConfig servletConfig) throws ServletException {

 String param = servletConfig.getServletContext().getInitParameter("param_name");

}

In JSF these parameters are accessible via ExternalContext, which should be pretty obvious and intuitive why. Since these parameters are not specific to JSF API (or JSF context) being specific to the environment in which JSF application run (e.g. Servlet or Portlet), they are available via ExternalContext as (more details about ExternalContext  are available here):

String param = FacesContext.getCurrentInstance().

               getExternalContext().getInitParameter("param_name");

Or, in a JSF page you can access it like this:

<h:outputText value="#{initParam['param_name']}"/>
<h:outputText value="#{facesContext.externalContext.initParameterMap['param_name']}"/>

! OmniFaces provides a shortcut for the above code as: String param = Faces.getInitParameter("param_name");

In order to obtain the parameter name-value pairs of all <context-param> entries in web.xml, you can do this:

Map<String, String> params = FacesContext.getCurrentInstance().

                             getExternalContext().getInitParameterMap();

! OmniFaces provides a shortcut for the above code as: Map<String, String> params = Faces.getInitParameterMap(); This map is also available in page via #{initParam} implicit object, and starting with JSF 2.3 is injectable as: @Inject @InitParameterMap private Map<String, String> initMap;

Most of the time such parameters are used for providing different configurations. For example, Bauke Scholtz (aka BalusC) provides in What Mojarra context parameters are available and what do they do? a comprehensive list of built-in context parameters for Mojarra. Obviously, all these parameters are internally recognized by Mojarra and they allows us to interfere for exterior in how Mojarra and our application will work in our case. Think of these parameters as a convenient way to fine-tune Mojarra without programmatic involvement. Sometimes, is even necessary to configure some context parameters (e.g. for defining taglibs locations).

Beside these parameters, you can define your own. For example:

<context-param>

 <param-name>number.one.in.ATP</param-name>

 <param-value>Rafael Nadal</param-value>

</context-param>

Context parameters are eligible for EL also:

<context-param>

 <param-name>number.one.in.ATP</param-name>

 <param-value>#{fooBean.fooPlayer}</param-value>

</context-param>

Now, you can use number one in ATP in your application wherever you need. And, if number one in ATP changes then you can quickly align your configuration:

<context-param>

 <param-name>number.one.in.ATP</param-name>

 <param-value>Roger Federer</param-value>

</context-param>

This way your application doesn't need verbose refactoring!

! OmniFaces provides the possibility to inject context parameters by names. See here.

Do not use context parameters for dealing with users names and passwords. Don't do this:

<context-param>

 <param-name>user.email</param-name>

 <param-value>leoprivacy@yahoo.com</param-value>

</context-param>

<context-param>

 <param-name>user.password</param-name>

 <param-value>!@##$$dddlff</param-value>

</context-param>

There are at least six reasons for what you don't want to do that (or similar usage cases):

- an application has many users, is verbose to create a context parameter  / user

- user credentials are commonly used to link more personal data in the database; since you place them in web.xml you cannot perform queries that involves user credentials;

 - hard-coding passwords in web.xml is not a good idea from security reasons

- you simply break down the web.xml purpose which is dedicated for configurations, not for persistence;

- you cannot perform elegant bulk-queries (e.g. delete all users ...);

- you cannot take advantage of authentication mechanisms (e.g. FORM, etc).

As a rule, keep context parameters for application initialization/configuration stuff!