PDA

View Full Version : ReloadableResourceBundleMessageResource loading messages, but not reloading


erntheburn
Sep 12th, 2007, 03:23 PM
I have access to the resources I have configured using the taglib <spring:message ..., however, when I edit the property in the property file, and I reload the JSP after a period greater than the cacheSeconds value, it does not get reloaded in the JSP. I have tried setting the cacheSeconds to various values, but to no avail. Here's my bean config:

<bean id="messageSource" class="org.springframework.context.support.ReloadableReso urceBundleMessageResource">
<property name="cacheSeconds" value="15"/>
<property name="basenames">
<list>
<value>/WEB-INF/properties/application</value>
<value>/WEB-INF/properties/sql</value>
<value>/WEB-INF/properties/labels</value>
</list>
</property>
<property name="defaultEncoding" value="UTF-8"/>
</bean>

And my taglib on my JSP:

My Number: <spring:message code="jag.number"/>

And property in jag.properties:

jag.number=123

The other question I have is, how can I access the properties from a Controller?

Thanks,
-ernie

Marten Deinum
Sep 12th, 2007, 03:27 PM
Not sure but I thought that the stuff under /WEB-INF isn't being monitored. You can only access/edit files outside of that scope. This is because the files get copied to a temp space and loaded from there. So when editing the original ones you aren't editing the ones it is monitoring.

pmularien
Sep 13th, 2007, 09:21 AM
@Marten, WEB-INF/classes (at least) is definitely OK, at least in Spring 1.x.

how can I access the properties from a Controller

Generally something like this:

String msg = getMessageSourceAccessor().getCode("jag.number");

Look at the Javadoc for MessageSourceAccessor (http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/context/support/MessageSourceAccessor.html) for the full range of available methods.

Marten Deinum
Sep 13th, 2007, 09:26 AM
/WEB-INF/classes is always being monitored (well at least if you have enabled hotdeployment in Tomcat if I'm not mistaken) all the other directories not.

For the remainder I agree :)

pmularien
Sep 13th, 2007, 09:28 AM
/WEB-INF/classes is always being monitored (well at least if you have enabled hotdeployment in Tomcat if I'm not mistaken) all the other directories not.
Interesting, thanks for the info. I was obviously too lazy to test it myself ;)

Marten Deinum
Sep 13th, 2007, 09:32 AM
Might be worth a test.

Also from the docs


* <p>In contrast to {@link ResourceBundleMessageSource}, this class supports
* reloading of properties files through the {@link #setCacheSeconds "cacheSeconds"}
* setting, and also through programmatically clearing the properties cache.
* Since application servers typically cache all files loaded from the classpath,
* it is necessary to store resources somewhere else (for example, in the
* "WEB-INF" directory of a web app). Otherwise changes of files in the
* classpath will <i>not</i> be reflected in the application.


Although it makes the problem not easier because the /WEB-INF/properties isn't part of the classpath, normally at least. Hmm ponder on this I will...

erntheburn
Sep 13th, 2007, 09:54 AM
It appears that resources in /WEB-INF must be in /WEB-INF/classes in order to reload, doesn't work otherwise. The API documentation cleary suggests that the property file could be /WEB-INF/<property>. here's what is in the Javadoc:

Set an array of basenames, each following the basic ResourceBundle convention of not specifying file extension or language codes, but in contrast to ResourceBundleMessageSource referring to a Spring resource location: e.g. "WEB-INF/messages" for "WEB-INF/messages.properties", "WEB-INF/messages_en.properties", etc.
As of Spring 1.2.2, XML properties files are also supported: e.g. "WEB-INF/messages" will find and load "WEB-INF/messages.xml", "WEB-INF/messages_en.xml", etc as well. Note that this will only work on JDK 1.5+.

BTW, I'm using java 1.5.

Ideally I would like to place these resources outside the WAR or EAR, in a directory outside the application context. It looks like the best way to do this is to plug in something other than the default resource lodaer. Looks like FileSystemResourceLoader is the way to go. If I did this, would the baseNames start at the contextual root of the directory I specify in the FileSystemResourceLoader?

Thanks for all your help,
-ernie

Marten Deinum
Sep 13th, 2007, 10:05 AM
We load some property files outside the classpath just prefix them with file: and include the fullpath. If you configure a PropertyPlaceHolderConfigurer you can even include system parameters. We point to the ${CATALINA_HOME}/conf/properties.properties and load it from there.