[ Forgive the re-post.... I wanted to give this a more meaningfull subject. ]
I was poking around the comments for this bug when I noticed the following passage: >>>> 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). I want to mention a scenario when I might want to have the MesssageResources stored in the Request... We are writing a hosted application that can have client-specific resource mappings (e.g. logos). One possible solution would be to pre-process the request looking for the client ID in the session (it gets put there during login) and figure out which MessageResources should be placed into the Request. This could not be done seemlessly in Stuts 1.0 because the framework would *always* look in the application context for the MessageResources so there was no way for me to handle multiple customizations within a single app context. By extending the framework (specifically RequestUtils.getMessage) to look in the request for overrides, I now had a way to interpose my overrides without having to change any of the existing framework (e.g. I could use the existing taglibs instead of writing my own to call my own version of RequestUtils.getMessage). This, of course, presumes that you guys would have been willing to commit to this "implicit context" as a "public interface". I realize what I'm doing would have to be done carefully to make sure I don't break other assumptions but it seems like a resonably elegant way to solve my problem. BTW (I know I might get smacked for asking this question in this forum) if anyone has a suggestion for an alternative solution to my problem I'm all ears (but send it to me privately so I don't get into REALLY big trouble for my first posting! :-) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
