{"id":1597,"date":"2010-11-15T08:26:08","date_gmt":"2010-11-15T13:26:08","guid":{"rendered":"http:\/\/www.andygibson.net\/blog\/?p=1597"},"modified":"2015-08-16T11:16:49","modified_gmt":"2015-08-16T10:16:49","slug":"resource-bundles-in-jsf-2-0-applications","status":"publish","type":"post","link":"https:\/\/www.andygibson.net\/old-blog\/article\/resource-bundles-in-jsf-2-0-applications\/","title":{"rendered":"Resource Bundles in JSF 2.0 Applications"},"content":{"rendered":"

Setting up resource message bundles in JSF to provide multilingal messages and captions is often overlooked when first creating an application. Leaving it till later in the project means you will have to go back and manually change the constants over to resource based values. Resource bundles JSF 1.2 were far from perfect but fortunately, using resource bundles in JSF 2.0 is very easy and this tutorial will show you how to add bundles and use them in your JSF 2.0 pages.
\n
\nFor this example, we’ll create a new application using the jee6-servlet-basic-archetype<\/code> Knappsack Maven archetype. The full source can be downloaded<\/a> and run using mvn clean jetty:run<\/code> from the command line.<\/p>\n

Message resources are stored in properties files which consist of name value pairs that binds a message key string with the message value. We’ll use the following example<\/p>\n

\r\nfirstName=First Name\r\nlastName=Last Name\r\nforgotPassword=Forgot Password?\r\nusernameTaken={0} is already taken\r\n<\/pre>\n
This file needs to be saved and referenced in a package, which would normally be in the same place as your source code, but Maven provides a separate area for resources. Save the file in the src\/main\/resources\/org\/fluttercode\/resourcedemo\/<\/code> folder with the name MessageResources.properties<\/code>. Open up the faces-config<\/code> file and add the following XML :<\/code><\/code><\/p>\n
\r\n<application>\r\n\t<resource-bundle>\r\n\t\t<base-name>org.fluttercode.resourcedemo.MessageResources<\/base-name>\r\n\t\t<var>msgs<\/var>\r\n\t<\/resource-bundle>\r\n<\/application>\r\n<\/pre>\n
Here, we have told JSF about the resource bundle and assigned a variable name to it. Now we will go and add a reference to one of the messages in our home page. Open home.xhtml<\/code> and replace the initial message with the following :<\/p>\n
\r\n<h:outputText  value="#{msgs.firstName}"\/>\r\n<\/pre>\n
This is a JSF output text component that gets its value from the resource bunde, in this case, the firstName<\/code> value. If you are using JBoss Tools, you will see that it can perform autocompletion for you on both the msgs<\/code> value and the actual property keys on the msgs<\/code> resources. It also displays the actual property value in the preview window for the page. If you run the app now by typing mvn jetty:run<\/code> in the command line, you will see that the word First Name<\/code> appears in the page.<\/p>\n
Access Resources From Code<\/h1>\n
Typically, in your application you will generate messages for the user that also needs to be obtained from the resource bundle. To do this, we will create a bean that can fetch the resource bundle for us and extract strings from it.<\/p>\n
\r\npublic class MessageProvider {\r\n\r\n\tprivate ResourceBundle bundle;\r\n\r\n\tpublic ResourceBundle getBundle() {\r\n\t\tif (bundle == null) {\r\n\t\t\tFacesContext context = FacesContext.getCurrentInstance();\r\n\t\t\tbundle = context.getApplication().getResourceBundle(context, \"msgs\");\r\n\t\t}\r\n\t\treturn bundle;\r\n\t}\r\n\r\n\tpublic String getValue(String key) {\r\n\r\n\t\tString result = null;\r\n\t\ttry {\r\n\t\t\tresult = getBundle().getString(key);\r\n\t\t} catch (MissingResourceException e) {\r\n\t\t\tresult = \"???\" + key + \"??? not found\";\r\n\t\t}\r\n\t\treturn result;\r\n\t}\r\n\r\n}\r\n<\/pre>\n
This class fetches the resource bundle from the faces context which will determine the best bundle to use based on the supported locales and the client locale. The second method uses the first method to fetch a string resource from the bundle.
\nWe’ll create a JSF backing bean to use this bean to return a message to the user.<\/p>\n
\r\n@Named\r\n@RequestScoped\r\npublic class SomeBean {\r\n\r\n\tpublic String getMessage() {\r\n\t\tString msg = new MessageProvider().getValue(\"someMessage\");\r\n\t\treturn MessageFormat.format(msg, \"SomeValue\");\r\n\t}\r\n}\r\n<\/pre>\n
In our home.jsf<\/code> page, we display our message by adding<\/p>\n
\r\nMessage = #{someBean.message}\r\n<\/pre>\n
Which results in the following phrase being displayed :<\/p>\n
\r\nMessage = SomeValue is not valid\r\n<\/pre>\n
Having just the one default properties file in place is the bare minimum for using string resource bundles in your applications, and I would recommend using that for any application, even if it is never going to be multi-lingual. At the very least, it keeps your string constants in one place and at best, it makes it really easy to support multiple languages at a later date.<\/p>\n
Handling JSF Locale Information<\/h1>\n
If you go multi-lingual you will need to provide multiple versions of the resource file for different locales, and list the supported locales in your faces-config.xml<\/code> file.
\nTo test this, create multiple copies of the MessageResources<\/code> file in the same directory with different names such as MessageResources_de.properties<\/code> or MessageResources_fr.properties<\/code> and in the content for each, use the same values, but add the locale on the end.<\/p>\n
MessageResources_fr.properties<\/b><\/p>\n
\r\nfirstName=First Name(fr)\r\nlastName=Last Name(fr)\r\nforgotPassword=Forgot Password?(fr)\r\nsomeMessage={0} is not valid(fr)\r\n<\/pre>\n
In the faces-config.xml<\/code> file you can add the supported locales and set the default locale to use.<\/p>\n
\r\n\t<application>\r\n\t\t<locale-config>\r\n\t\t\t<default-locale>en_US<\/default-locale>\r\n\t\t\t<supported-locale>de<\/supported-locale>\r\n\t\t\t<supported-locale>en_GB<\/supported-locale>\r\n\t\t\t<supported-locale>fr<\/supported-locale>\r\n\t\t<\/locale-config>\r\n\t\t<resource-bundle>\r\n\t\t\t<base-name>org.fluttercode.resourcedemo.MessageResources<\/base-name>\r\n\t\t\t<var>msgs<\/var>\r\n\t\t<\/resource-bundle>\r\n\t<\/application>\r\n<\/pre>\n
Now, depending on where you are in the world, and your browser locale, if you plan on following along, you’ll have to substitute your own locale for en_US. Since we have a MessageProperties<\/code> file without a locale in the file name, if it cannot find a matching locale, it will use this default bundle. If the default locale is specified in faces-config<\/code>,then that locale will be used instead of the non-specific default.
\nPlay around with renaming some of the resource files, especially the file that matches your own locale. If the file exists, but it is not included in the list of supported locales in faces-config<\/code> it won’t be used. You can also change the default-locale<\/code> value to one other than your own locale and see how the locale would be selected.
\nJSF will also select a locale that matches based on the language if not the specific region. In my case, having a locale of en_US<\/code> means that if available, JSF will select the MessageResources_en<\/code> bundle if there is no bundle specifically for en_US<\/code>.<\/p>\n
Download the Maven source code <\/a> for this project and run it locally by unzipping it into a folder and typing mvn clean jetty:run<\/code> and going to http:\/\/localhost:8080\/resourcedemo\/<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Setting up resource message bundles in JSF to provide multilingal messages and captions is often overlooked when first creating an application. Leaving it till later in the project means you will have to go back and manually change the constants over to resource based values. Resource bundles JSF 1.2 were far from perfect but fortunately, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0},"categories":[63],"tags":[32],"_links":{"self":[{"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/posts\/1597"}],"collection":[{"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/comments?post=1597"}],"version-history":[{"count":16,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/posts\/1597\/revisions"}],"predecessor-version":[{"id":2144,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/posts\/1597\/revisions\/2144"}],"wp:attachment":[{"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/media?parent=1597"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/categories?post=1597"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.andygibson.net\/old-blog\/wp-json\/wp\/v2\/tags?post=1597"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}