Comment RE: Bug 11932

[Charles Fineman <fi...@alumni.cmu.edu>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>