DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2003-01-19 19:16 --- We should visit this in 1.2.x when the entire approach to modules might be re-examined. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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] 2003-01-05 15:31 --- A comment about the statement Is there a benifit that results form taking the correct message resources from the servlet context and putting them in the request? The benefit would be if you want to have something in the session or request drive the decision of which MessageResources to use. In the current (1.0) system, RequestUtils.getMessage always goes to this APPLICATION_SCOPE to find the MessageResources so there is no way to override this for a particular request/session. In my case, I am writing a hosted application that can have client-specific resource mappings (e.g. logos). To be sure there are other ways I could solve this but none seem as elegant as being able to put an override in the request context and having RequestUtils look there before falling back to the application scoped default. One could argue that this is a slippery slope... why just allow for one override, why not multiple? One way might be to support looking for an ordered list of MessageResources in the request scope. Another would be to punt and make developers who want to leverage this be responsible to explicitly default from their interjected MessageResources to the one originally stored in the session (the module-specific one in this particular case). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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]
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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-19 16:58 --- Note that basically the following methods need to be in sync when it comes to dealing with the MessageResources objects: ActionServlet.initApplicationMessageResources(ApplicationConfig) RequestUtils.selectApplication(String, HttpServletRequest, ServletContext) RequestUtils.message(PageContext, String, String, Object) In 1.1 b2 they're pretty much out of sync :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-10-30 22:07 --- This is a duplicate of #14092, which has a propsed patch, so I'm setting this one (even though it was logged first) *** This bug has been marked as a duplicate of 14092 *** -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2002-10-31 00:15 --- Reopening because I believe they are different problems. Bug #14092 is about a problem with RequestUtils.present(), where it is looking in the wrong scope for the message bundle. Bug #11932 (this bug) is about a problem with RequestUtils.message(), where the module prefix is not being taken into account when looking for the bundle. One other point to note is that the code in these two methods is very similar, and the common part - including the fix for the module prefix - should probably be factored out into a separate private method. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
