How to update the JSF2.0 (Primefaces) tooltips dyn

Question

I need to update the JSF2.0 (Primefaces) tooltips dynamically without server restart.

Meaning need to find a way where tooltips (atm from properties file) of the a running application can be changed without requiring a server restart.

We are running websphere and deploying a non exploded EAR (can probably convince to deploy exploded war)

Any Ideas or tips please. Thanks you

Answer 1

The value attribute of the p:toolTip component must be an EL expression or a literal text. Usually, one would reference a resource bundle declared using the var attribute of the f:loadBundle tag, in the EL expression for the tooltip.

The underlying resource bundle declared using the basename attribute could be backed by a property file itself (in which case you need to place the property file in the appropriate directory on the classpath), or for that matter it could be a custom ResourceBundle implementation that could read from a properties file (located outside the container), or a database or any store for that matter.

You could therefore change your existing EL expression from the existing one defined as:

<f:loadBundle var="msg" basename="propfile_location" />

to

<f:loadBundle var="msg" basename="fully qualified class name of the ResourceBundle class" />

In simpler words, you will need to roll your own ResourceBundle class(es) to support the various locales. Needless to state, but you will need to override the ResourceBundle.getObject(java.lang.String) method, as it is invoked by the ResourceBundleELResolver implementation when evaluating the EL expressions referencing ResourceBundles.

Additionally, you will need to ensure that the ResourceBundle.getObject(java.lang.String) implementation of your ResourceBundle will always re-fetch and return the value corresponding to the provided key. Failure to ensure this would mean that the initial value fetched by the resource bundle may be returned on subsequent invocations, especially if you are caching the initial value. You are likely to encounter this behavior even if you deploy an exploded WAR file where you can modify the property file contents without a redeployment of the application, and that is why it is important to use a custom ResourceBundle implementation that does not cache values.