Message Resource is not multi-app aware (was: Comment RE: Bug 11932)

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

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