DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11932>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11932
(Message Resource is not multi-app aware) Multi-Resource not work in
Multi-Appliction config environment
------- Additional Comments From erwin.vervaet@xxxxxx 2002-11-20 14:32 -------
I've implemented a quick & dirty solution for the issue:
1) ActionServlet.initApplicationMessageResources(ApplicationConfig)
This method now puts the messages resources in the servlet context using as a
key "Action.MESSAGES_KEY + prefix + bundle":
getServletContext().setAttribute(Action.MESSAGES_KEY + config.getPrefix() + mrcs
[i].getKey(), resources);
2) RequestUtils.selectApplication(String, HttpServletRequest, ServletContext)
This method no longer deals with message resources. In 1.1 b2 it puts the
correct message resource for a sub-app in the request. However, it was not
dealing with possible bundle keys. Is there a benifit that results form taking
the correct message resources from the servlet context and putting them in the
request? I could not think of any so I removed all the code from this method
that deals with MessageResources objects (the last 7 lines).
3) RequestUtils.message(PageContext, String, String, Object) and
RequestUtils.present(PageContext, String, String, Object)
These methods use a new method "getMessageResources(PageContext pageContext,
String bundle)" to get a correct message resources object. This new method
factors out the common logic for these 2 methods, as Martin suggested.
The getMessageResources() method basically just retreives the correct
MessageResources object from the ServletContext (that was put there by the
initApplicationMessageResources() method).
|
