Is it possible to supply a new PropertiesConfiguration file at runtime?

Question

Background:

I have a requirement that messages displayed to the user must vary both by language and by company division. Thus, I can't use out of the box resource bundles, so I'm essentially writing my own version of resource bundles using PropertiesConfiguration files.

In addition, I have a requirement that messages must be modifiable dynamically in production w/o doing restarts.

I'm loading up three different iterations of property files:

-basename_division.properties
-basename_2CharLanguageCode.properties
-basename.properties

These files exist in the classpath. This code is going into a tag library to be used by multiple portlets in a Portal.

I construct the possible .properties files, and then try to load each of them via the following:

PropertiesConfiguration configurationProperties;
try {
    configurationProperties = new PropertiesConfiguration(propertyFileName);
    configurationProperties.setReloadingStrategy(new FileChangedReloadingStrategy());
} catch (ConfigurationException e) {
    /* This is ok -- it just means that the specific configuration file doesn't 
       exist right now, which will often be true. */
    return(null);
}

If it did successfully locate a file, it saves the created PropertiesConfiguration into a hashmap for reuse, and then tries to find the key. (Unlike regular resource bundles, if it doesn't find the key, it then tries to find the more general file to see if the key exists in that file -- so that only override exceptions need to be put into language/division specific property files.)

The Problem:

If a file did not exist the first time it was checked, it throws the expected exception. However, if at a later time a file is then later dropped into the classpath and this code is then re-run, the exception is still thrown. Restarting the portal obviously clears the problem, but that's not useful to me -- I need to be able to allow them to drop new messages in place for language/companyDivision overrides w/o a restart. And I'm not that interested in creating blank files for all possible divisions, since there are quite a few divisions.

I'm assuming this is a classLoader issue, in that it determines that the file did not exist in the classpath the first time, and caches that result when trying to reload the same file. I'm not interested in doing anything too fancy w/ the classLoader. (I'd be the only one who would be able to understand/maintain that code.) The specific environment is WebSphere Portal.

Any ways around this or am I stuck?

nobeh · Answer 1 · 2012-03-29T18:01:22.300

My guess is that I am not sure if Apache's FileChangedReloadingStrategy also reports the events of ENTRY_CREATE on a file system directory.

If you're using Java 7, I propose to try the following. Simply, implement a new ReloadingStrategy using Java 7 WatchService. In this way, every time either a file is changed in your target directories or a new property file is placed there, you poll for the event and able to add the properties to your application.

If not on Java 7, maybe using a library such as JNotify would be a better solution to get the event of a new entry in a directory. But again, you need to implement the ReloadingStrategy.

UPDATE for Java 6:

PropertiesConfiguration configurationProperties;
try {
    configurationProperties = new PropertiesConfiguration(propertyFileName);
    configurationProperties.setReloadingStrategy(new FileChangedReloadingStrategy());
} catch (ConfigurationException e) {
    JNotify.addWatch(propertyFileDirectory, JNotify.FILE_CREATED, false, new FileCreatedListener());
}

where

class FileCreatedListener implements JNotifyListener {
  // other methods

  public void fileCreated(int watchId, String rootPath, String fileName) {
    configurationProperties = new PropertiesConfiguration(rootPath + "/" + fileName);
    configurationProperties.setReloadingStrategy(new FileChangedReloadingStrategy());
    // or any other business with configurationProperties
  }

}

Actually, the `ConfigurationException` is thrown on the constructor. And I never stop getting the Exception, even if this file has been dropped. So, implementing my own `FileChangedReloadingStrategy` won't help directly. (In my case, it's Java 6). — Mike Ryan, Mar 29 '12 at 13:58
I believe receiving the exception makes sense. The `FileChangedReloadingStrategy` is used to monitor a "file change" which means you're assuming the file already exists; so it does not report a new file being dropped in the directory because it did not exist before. That's why I believe you need to have a modified version, let's call it `NewFileReloadingStrategy` to catch the event that a new file is dropped in the directory. Since you're using Java 6, does giving JNotify a try feasible for you to receive the event of a new file in the directory? — nobeh, Mar 29 '12 at 17:50
That makes more sense now -- I didn't see what you meant earlier. I'll try and put this together this weekend to see if it works as expected. — Mike Ryan, Mar 30 '12 at 14:38

Is it possible to supply a new PropertiesConfiguration file at runtime?

1 Answers1