ResourceBundleViewResolver - read property file that does not exist on classpath

Question

I am not able to read a property file using ResourceBundleViewResolver (e.g.: views.properties) that exists on unix file system and not on classpath. Using spring-webmvc-3.2.4. I could have placed the properties file on classpath (i.e., inside WEB-INF/classes/) but do not want to redeploy the war upon changing a single entry in property file.

Reasons for not to redeploy war: 1) Occasionally, jsp names need to be changed on production environment. Though this rare but used for quick resolution.

2) I am used to mentioning view names in property file, and a restart will help. [ I am thinking bit ambitious too in coming releases but not quite sure how far it could be achieved. Like, wanted to also implement WatchService that helps to avoid restarting server on property file changes. Not quite sure, how this WatchService could be linked on ResourceBundleViewResolver but have seen posts on using it for reading dao.properties references: Spring Bean running in its own thread, http://e-blog-java.blogspot.com/2011/03/how-to-watch-file-system-for-changes-in.html ]

3) The company i work do not have admins, and i wanted to be less error-prone and wanted to avoid deploying wars as much as i can.

Primarily when posted this question, i was looking into reading an external property file for ResourceBundleViewResolver but if i can also get stackoverflow community views on able to read the values from views.properties dynamically upon changing without need to restart server will be awesome.

Thanks for your time.

Answer 1

There are two parts to my answer.

Firstly, you will not be able to achieve what you want with the ResourceBundleViewResolver. This works with ResourceBundles which by definition must be available on your classpath. You will therefore have to put views.properties onto the classpath for it to work.

Secondly about dynamically reloading view resolution.

You may be able to achieve what you want with the org.springframework.web.servlet.view.XmlViewResolver and ensuring that caching of views is turned off. So move your views.properties into an XML configuration and place that on the filesystem. However that would probably turn out to be fairly expensive in terms of processing an XML configuration for each request. You would have to try it and find out but it doesn't sound ideal.

Alternatively and as already suggested, you could roll your own ViewResolver implementation to achieve what you want.

I would however ask you to stop and think about what you're trying to do. I would suggest that your production environment should be a snapshot of a well tested, known working state. The types of changes that you are talking about should be tested before being pushed into the production environment. If things go wrong, then you can immediately roll-back to the last known working snapshot.

Re-starting the server is a small pain, but in reality how often are you going to need to do that? I would also suggest that having a non-technical team simply copy a known working WAR file into a specific location is less error prone that editing a properties file?