Dear Spring team:

I want to use ReloadableResourceBundleMessageSource for international resource.

I try use *_en to match a file's name and reload properties, but I think it is not supported when I found it uses getResource() for the location of the resource.

I suggest we can use getResources() and use PathMatchingResourcePatternResolver for resolve.

Thanks

Comment From: sbrannen

Hi @huayu611,

I try use *_en to match a file's name and reload properties, but I think it is not supported when I found it uses getResource() for the location of the resource.

Where did you try to supply the *_en pattern -- for example, to what method in which class?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: huayu611

Hi @sbrannen

sorry for reply late

first i think it's not issue , the spring document not introduced this . i only think if we have this feature, it's better for frame code manager .

class package :org.springframework.context.support.ReloadableResourceBundleMessageSource

the class is : ReloadableResourceBundleMessageSource and the method is refreshProperties.

in this class, we can configure the basenames for resource name ,

I will use in common frame , and other jar will use this feature , it will set basenames again.

e.g.: in common frame , i use "common_message_en.properties" and in other jar , i want to use "business_message_en.properties"

code (i can't override it ):

    protected PropertiesHolder refreshProperties(String filename, @Nullable PropertiesHolder propHolder) {
        long refreshTimestamp = (getCacheMillis() < 0 ? -1 : System.currentTimeMillis());

        Resource resource = this.resourceLoader.getResource(filename + PROPERTIES_SUFFIX);
        if (!resource.exists()) {
            resource = this.resourceLoader.getResource(filename + XML_SUFFIX);
        }

Comment From: sbrannen

Hi @huayu611,

I'm afraid I don't really understand what you're asking for.

When one of the getMessage(...) methods is invoked on a ReloadableResourceBundleMessageSource, that invocation internally delegates to ReloadableResourceBundleMessageSource.resolveCode(String, Locale) which resolves a MessageFormat by looking up the given message code in using the supplied Locale in all of the configured resource bundles (i.e., based on the basenames you configured -- such as "common_message" and "business_message").

If the supplied Locale is for English, the ReloadableResourceBundleMessageSource looks up the appropriate English properties files, potentially refreshing them if necessary.

Thus, I am not sure why you want to override the implementation of refreshProperties(...).

So, please let me rephrase my question:

If you create a ReloadableResourceBundleMessageSource with the basenames configured as "common_message" and "business_message", what is it that does not work for you?

Comment From: huayu611

Hi @sbrannen

My code structure is 1+N, now I want to add a common feature on “1”, and I configure a general internationalization on “1”, for "N" just setting up a properties file .

"1": Layer 1 provides specifications.
"N" : layer follower it

Now my code: in "1" layer , i create an interface , and N layer implement the interface , we collect all the properties filename. after that ,"1" layer will invoke setBasenames(String... basenames)

my problem is that : i do not want the interafce , i only tell "N" layer ,my filename specification is "*_message.properties" is ok .

other issue, if we use same file name in differnt jar , new properties file will covers the old . (only for internationalization property)

thanks.

Comment From: jhoeller

As of 6.1, there is an overridable resolveResource method in ReloadableResourceBundleMessageSource, in addition the existing overridable calculateFilenamesForLocale method. However, please note that ReloadableResourceBundleMessageSource is strongly designed for pre-defined basenames for which it caches specific entries, even for non-existing files. We recommend a full list of basenames specified upfront, even if some of those do not always exist.