You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2003/01/05 16:31:50 UTC

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