Re: [Springframework-developer] ReloadableResourceBundleMessageSource and <fmt:message> tag

[<jue...@we...>]

You could let ReloadableResourceBundleMessageSource access a classpath =
resource via "classpath:xxx", to be able to share the resources with =
standard JSTL. However, classpath resources are not reloadable, as the =
classloader will always cache them for its lifetime.
=20
I guess there's no way around exposing Spring's MessageSource as JSTL =
LocalizationContext. That's what JstlView does automatically. To do this =
manually, you could put the following Java code block on the top of your =
JSP:
=20
  JstlUtils.exposeLocalizationContext(request, =
WebApplicationContextUtils.getWebApplicationContext(application));
=20
Or use error views via Spring's HandlerExceptionResolver, which can be =
of type JstlView too. (I assume you currently work with standard JSP =
error pages.)
=20
Regarding Spring's message tag: The attribute names follow Spring =
MessageSource conventions there, that's why stuff is called "code" and =
"text". MessageSource is a bit more generic than ResourceBundle: It =
doesn't assume that the passed-in "code" is necessarly a "key" in a =
properties file; the message could also be built in other ways.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Daniel Miller
Gesendet: Mi 07.07.2004 05:49
An: Springframework-Developer
Betreff: [Springframework-developer] =
ReloadableResourceBundleMessageSource and <fmt:message> tag



Hello,

I am having problems accessing my message resources when they are loaded =
with ReloadableResourceBundleMessageSource (RRBMS). When RRBMS is used, =
the properties files must be located outside the classpath to be =
reloadable. However, the JSTL <fmt:bundle> tag's "basename" attribute =
and the <fmt:message> tag's "bundle" attribute only accept a classpath =
url (e.g. basename=3D"com.example.messages"). It would be nice if they =
accepted file url's as well (e.g. =
basename=3D"WEB-INF/jsp/common/messages.properties"), but they don't :(

Normally this should not be a problem because Spring puts the message =
bundle where JSTL can find it when a JSTLView is rendered. However, I =
want to use message resources in error pages (404, 403, =
java.lang.Exception, etc.) which are not rendered by Spring. Error pages =
are configured in web.xml; the Spring context where the message source =
locations are configured is bypassed when they are rendered.

Is there any way to load message resources explicitly inside a jsp page =
when the properties file is not on the classpath? Could another tag be =
added to the Spring tag library that would fetch the message bundle(s) =
from the Srping configuration and/or load the bundle from the file =
resource?

Example usage:

<spring:bundle>
 <!--
   - [Reloadable]ResourceBundleMessageSource configured
   - in the Spring context is used to retrieve messages
   -->
 <fmt:message key=3D"some.message.key" />
</spring:bundle>

OR

<spring:bundle resource=3D"WEB-INF/jsp/common/messages.properties">
 <!--
   - Message resources are loaded from the location
   - specified by the "resource" attribute
   -->
 <fmt:message key=3D"some.message.key" />
</spring:bundle>

Aside: IMHO the "code" attribute of the <spring:message> tag should to =
be deprecated and changed to match JSTL "key" attribute. That would =
enable a developer to easily switch from <fmt:message> to =
<spring:message> without changing attribute name(s)--plus it's less =
attributes to remember because it's standard...even the Struts =
<bean:message> tag got that one right.

Thanks,
Daniel Miller





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer