This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
Using a standard spring PropertyPlaceholderConfigurer, properties will be read from a file. If the property file modified we need to shut down the application context and launch a new one to get new values from property file.
Can we do this with out relaunch application context(or restart server).
For now my code and configuration is like below
If I change the value of USER_NAME to Beta in property file i need to restart the context to get the new value assigned. But can I do this with out restarting the server or context in spring?
kiran nyala wrote: But can I do this with out restarting the server or context in spring?
Not easily, and even harder with a PropertyPlaceHolderConfigurer since these replacements are done on the BeanDefinition before the bean is even instantiated. Making changes then to the singleton beans into which these properties were injected at runtime is tricky.
There are people out there that have made this sort of work you would have to google around. What kind of properties are actually changing at runtime? Perhaps it makes more sense to store these in a database instead and make use of the @Cacheable annotation to expire it every so often so often or on some sort of event (like updating the db)
Alternatively spring is providing the facility to reload the property files using
An alternative implementation of a MessageSource is class ReloadableResourceBundleMessageSource. This class automatically reloads messages from resource bundles, according to a setup policy. The property cacheSeconds is used to specify the time (in seconds) a loaded resource bundle is kept before checking for a new reload. A value of -1 keeps resource bundle cached forever. A value of 1 or more is recommended for good performance in message resolution. This class also accepts file base prefixes in basenames (e.g. classpath:, file:).
The ReloadableMessageSource has been used for this purpose. As has Java 7's WatchService or pre-Java 7 the Apache commons-configuration library, to watch a file to see if it's changed. However the ReloadableMessageSource was designed more for resolving messages, with support for the parameterization and internationalization of those messages, although it could be used here as well.
The @Cacheable abstraction I mentioned before can wrap any method even one that just reads a properties file from the file system (or a db look-up). If put into a helper bean I think it achieves the goal much more easily. Alternatively a static utility class with WatchService on the properties file would also work, and would be less complex. Either of the last 2 solutions allow you to be a little more flexible with your refresh policy as well.