使用ReloadableResourceBundleMessageSource在类路径上动态加载文件

时间:2012-01-27 15:19:49

标签: java spring-mvc resourcebundle

我是Spring的新手,我正在尝试使用它的ReloadableResourceBundleMessageSource类。

我正在尝试使用它,以便我们不再需要重新启动我们的网络应用以更改属性文件。

我有一个网络应用程序(主要使用JSF)和一个单独的tar组件,其中包含我的所有属性文件。

属性tar的结构如下:

 - CompanyOneMessages.properties
 - CompanyOneMessages_fr_FR.properties
 - CompanyTwoMessages.properties
 - CompanyTwoMessages_fr_FR.properties
 - CompanyThreeMessages.properties
 - CompanyThreeMessages_fr_FR.properties
 - ...

将此tar解压缩并部署到服务器上的某个位置,该位置指定为在websphere配置中的类路径上。

我在applicationContext-config.xml中添加了以下内容:

<!-- Enable reloading of resource bundles without requiring web-app restart -->
    <bean id="messages"
        class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
        <property name="basenames">
            <list>  
                <value>classpath:com/resource/dynamic/CompanyOneMessages</value>
                <value>classpath:com/resource/dynamic/CompanyTwoMessages</value>
                <value>classpath:com/resource/dynamic/CompanyThreeMessages</value>              
            </list>
        </property>     
        <property name="cacheSeconds" value="1" />
    </bean>

    <!-- Declare location of bean to handle messages and define property reference 
         we will use to reference message properties throughout the presentation layer -->
    <bean id="myappMessages" class="com.myapp.resource.MyAPPMessages">
        <property name="messages" ref="messages" />
    </bean>

一切正常。

但是,它没有完全解决原始问题。 每当我想在我们的应用程序中添加新公司时,我都必须在applicationContext-config.xml文件中添加一个新行并重新部署/重新启动Web应用程序。

我希望能够简单地将新公司属性文件放入属性tar中,然后动态选择它。

是否可以扩展ReloadableResourceBundleMessageSource类,使其在应用程序启动时搜索属性文件的类路径并动态加载所有这些文件?

更新

这是我到目前为止所做的:

的applicationContext-config.xml中:

<bean id="messages" class="com.resource.MyAPPReloadableResourceBundleMessageSource">
</bean>

MyAPPReloadableResourceBundleMessageSource:

package com.myapp.resource;

import org.springframework.context.support.ReloadableResourceBundleMessageSource;

public class MyAPPReloadableResourceBundleMessageSource extends ReloadableResourceBundleMessageSource
{   
    public MyAPPReloadableResourceBundleMessageSource()
    {   
        getResourceBundlesMessages();

        // Simply single basename test
        setBasename("classpath:/resource/dynamic/companyOneMessages");      
    }

    @Override
    public void setBasename(String baesname)
    {
        System.out.println("In setBasename");
        super.setBasename(baesname);
    }

    @Override
    public void setBasenames(String[] baesnames)
    {
        System.out.println("In setBasenames");
        super.setBasenames(baesnames);
    }

    private String[] getResourceBundlesMessages()
    {
        String[] propertiesFiles = null;

        // How do I get all filenames with .properties under com.resources.dynamic? (location is under classpath)

        return propertiesFiles;
    }
}

所以我需要的是如何使用.properties扩展名获取类路径下所有文件的列表?

由于

托马斯

2 个答案:

答案 0 :(得分:4)

ReloadableResourceBundleMessageSource要求文件位于webapp /目录下,而不是在类路径中(它不能重新加载)。

答案 1 :(得分:2)

您正在扩展ReloadableResourceBundleMessageSource的正确道路。正如@JamesC所提到的,以及Spring ReloadableResourceBundleMessageSource的API文档:

  

由于应用程序服务器通常会缓存从类路径加载的所有文件,因此有必要将资源存储在其他位置(例如,在Web应用程序的“WEB-INF”目录中)。

我和你有类似的要求。解决它的是扩展ReloadableResourceBundleMessageSource并覆盖calculateAllFilenames(String basename, Locale locale)方法,而不仅仅是将语言代码附加到基本名称。

例如,如果我在/srv/myapp/messages下有所有外部消息属性文件(在文件系统中,不是类路径),则重写的方法将执行以下操作:

@Override
protected List<String> calculateAllFilenames(final String basename,
        final Locale locale) {

   return super.calculateAllFilenames("file:///srv/myapp/messages/" + basename, 
           locale);
}

就我而言,我的basenames列表是静态的,因此,我不必覆盖为每个基本名称调用calculateAllFilenames()的其他方法。

在您的特定情况下,我会使用Company作为基本名称,并覆盖calculateAllFilenames()来扫描类路径之外的目录以解析实际的基本名称,然后为每个解析后调用super.calculateAllFilenames() basename(即super.calculateAllFilenames("file:///path/to/CompanyOneMessages", locale))。潜在地,与https://stackoverflow.com/a/11223178/1034436类似的东西会有所帮助。注意:与引用的答案不同,如果已解析的基本名称列表可以动态更改,我不会将目录扫描作为属性设置器的一部分。当然,还需要权衡您的应用程序的性能注意事项,因为它显然会大大增加文件系统访问。