Java – Spring MVC ResourceBundleMessageSource XML configuration

jakarta-eejavaspringspring-mvcspring-roo

I would like to mimic the Grails way of resolving i18n messages.

In WEB-INF/i18n/ I have the following directories:

admin/messages_EN.properties

admin/messages_FR.properties

website/messages_EN.properties

website/messages_FR.properties

please ignore the language endings ( EN and FR ) in this example

in my xml configuration I currently have:

<!-- Register the welcome.properties -->
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
  <property name="defaultEncoding" value="utf-8" />
  <property name="basename" value="/WEB-INF/i18n/" />
</bean>

What I am looking for here, is a way to tell Spring to look for .properties files under i18n but without explicitly telling it what each subdirectory is. That is without a list of basenames that points to /WEB-INF/i18n/admin/ and /WEB-INF/i18n/website/

I want the WEB-INF/i18n/ directory to be dynamic, and that bundles ( directories ) can be created without having to remodify the xml configuration file.

I am not trying to solve this particular example with admin and website sub directories

Is this possible?

Thanks!

Best Answer

Here is the solution:

package com.mypackage.core.src;

import java.io.File;
import java.util.ArrayList;

import javax.servlet.ServletContext;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.support.ReloadableResourceBundleMessageSource;

public class UnderDirectoryReloadableResourceBundleMessageSource extends ReloadableResourceBundleMessageSource {

    @Autowired
    ServletContext servletContext;

    public void setWorkingDirectory(String directoryPath) {
        File rootDir = new File( servletContext.getRealPath(directoryPath) );
        ArrayList<String> baseNames = new ArrayList<String>();
        iterateScanDirectoryAndAddBaseNames(baseNames, rootDir);
        setBasenames(baseNames.toArray(new String[baseNames.size()]));
    }

    private void iterateScanDirectoryAndAddBaseNames(ArrayList<String> baseNames, File directory) {
        File[] files = directory.listFiles();

        for (File file : files) {
            if (file.isDirectory()) {
                iterateScanDirectoryAndAddBaseNames(baseNames, file);
            } else {
                if (file.getName().endsWith(".properties")) {
                    String filePath = file.getAbsolutePath().replaceAll("\\\\", "/").replaceAll(".properties$", "");
                    filePath = filePath.substring(filePath.indexOf("/WEB-INF/"), filePath.length());
                    baseNames.add(filePath);
                    System.out.println("Added file to baseNames: " + filePath);
                }
            }
        }
    }

}

XML config:

<bean id="messageSource" class="com.mypackage.core.src.UnderDirectoryReloadableResourceBundleMessageSource">
  <property name="defaultEncoding" value="utf-8" />
  <property name="workingDirectory" value="/WEB-INF/webspring/i18n" />
  <property name="cacheSeconds" value="3" />
  <property name="fallbackToSystemLocale" value="false" />
</bean>

Enjoy!

Related Solutions

R – Multiple messageSources in Spring configuration files

I have used the Message Sources in Spring for some i18n support. In my case I only needed one so it was easy to inject the one message source I needed into the service bean that I was creating.

I was hoping to see something like what I will propose later on in the Spring sources itself. But I don't see anything that will aggregate heterogeneous message sources. If all of them will be parts of a resource bundle like property files, I'm sure you could write a wrapper for ResourceBundleMessageSource that could be dynamically updated as beans were registered.

However, if you wanted to aggregate heterogeneous MessageSources, this is what I would suggest. Create an message source aggregating bean that upon loading asks the ApplicationContext for beans of type MessageSource.class. This aggregating bean can then let each source attempt to resolve the key and format the message. Depending on how many files/msg source classes you have you may want to allow the aggregating implementation to prioritize which ones it attempts to use first. If performance becomes a problem, you could also cache which source resolved which keys so that the aggregator doesn't have to guess each time.

Java – How does autowiring work in Spring

First, and most important - all Spring beans are managed - they "live" inside a container, called "application context".

Second, each application has an entry point to that context. Web applications have a Servlet, JSF uses a el-resolver, etc. Also, there is a place where the application context is bootstrapped and all beans - autowired. In web applications this can be a startup listener.

Autowiring happens by placing an instance of one bean into the desired field in an instance of another bean. Both classes should be beans, i.e. they should be defined to live in the application context.

What is "living" in the application context? This means that the context instantiates the objects, not you. I.e. - you never make new UserServiceImpl() - the container finds each injection point and sets an instance there.

In your controllers, you just have the following:

@Controller // Defines that this class is a spring bean
@RequestMapping("/users")
public class SomeController {

    // Tells the application context to inject an instance of UserService here
    @Autowired
    private UserService userService;

    @RequestMapping("/login")
    public void login(@RequestParam("username") String username,
           @RequestParam("password") String password) {

        // The UserServiceImpl is already injected and you can use it
        userService.login(username, password);

    }
}

A few notes:

In your applicationContext.xml you should enable the <context:component-scan> so that classes are scanned for the @Controller, @Service, etc. annotations.
The entry point for a Spring-MVC application is the DispatcherServlet, but it is hidden from you, and hence the direct interaction and bootstrapping of the application context happens behind the scene.
UserServiceImpl should also be defined as bean - either using <bean id=".." class=".."> or using the @Service annotation. Since it will be the only implementor of UserService, it will be injected.
Apart from the @Autowired annotation, Spring can use XML-configurable autowiring. In that case all fields that have a name or type that matches with an existing bean automatically get a bean injected. In fact, that was the initial idea of autowiring - to have fields injected with dependencies without any configuration. Other annotations like @Inject, @Resource can also be used.

Best Answer

Related Solutions

R – Multiple messageSources in Spring configuration files

Java – How does autowiring work in Spring

Related Topic