When ReloadableResourceBundleMessageSource.getMessage() is called, cache is initiated with basenames values present at the moment of invocation (in method getMergedProperties()).
When new basenames are added (method addBasenames()) or changed (method setBasenames()), cache is not invalidated, although it is stale given the new basenames.
The proposed fix addresses this problem by invalidating cache at those two points.
Comment From: pivotal-cla
@ahmadshahwan Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: pivotal-cla
@ahmadshahwan Thank you for signing the Contributor License Agreement!
Comment From: snicoll
Thanks for the PR but those setters are meant to configure a ReloadableResourceBundleMessageSource on startup, not manipulate it once the context has started. If you wish to do so, clearing the cache using the existing method is what you should be doing. I understand that the PR looks like it's doing the right thing but there are many other places in the framework where setters are used to configure a bean and further modification of it at runtime requires special handling.