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 [EMAIL PROTECTED] 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). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
