MessageResources is not module aware

• Key: STR-798
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Martin Cooper
• Reporter: Alex Kwan
• Component/s: Core
• Affects Version/s: Nightly Build
• Fix Version/s: 1.2 Family

Environment

Operating System: other
Platform: All

Description

Suppose we define a sub app in web.xml as below

...
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/configs/default/struts-config.xml</param-value>
</init-param>
<init-param>
<param-name>config/sample</param-name>
<param-value>/WEB-INF/configs/sample/struts-config.xml</param-value>
</init-param>
...

and in the default struts-config.xml file,
we add the following message resouces

...
<message-resources parameter="DefaultMessageResources"/>
<message-resources key="IMAGE_RESOURCES_KEY" parameter="DefaultImageResources"/>
...

now we create two message resources in the sub app sample's struts-config.xml

...
<message-resources parameter="SampleMessageResources"/>
<message-resources key="IMAGE_RESOURCES_KEY" parameter="SampleImageResources"/>
...

then we create a test.jsp in path /webroot/sample/
the file contains the following line

...
<bean:message key="test"/>
...
<html:img bundle="IMAGE_RESOURCES_KEY" pageKey="test.img"/>
...

the problem is the message tag renders fine but the img tag came out with
something like <img src="http://hostaddress/contextPath/samplenull

I checked the source of class ImgTag and found it get the src path through

...
return (request.getContextPath() + config.getPrefix() +
        RequestUtils.message(pageContext, getBundle(), getLocale(),
this.pageKey));

...

but in RequestUtils.message method

        // Look up the requested MessageResources
        if (bundle == null) {
            bundle = Action.MESSAGES_KEY;
            resources = (MessageResources)
                pageContext.getAttribute(bundle, PageContext.REQUEST_SCOPE);


        }
        if (resources == null) {
            resources = (MessageResources)
                pageContext.getAttribute(bundle,
                                         PageContext.APPLICATION_SCOPE);
        }

it simply first check for the default message then go to get bundle int
application scope.
so if i want use the img tag, I must specify the bundle as
bundle="IMAGE_RESOURCES_KEY/sample"

Now my question is whether we can just use the img tag as the message tag, like
bundle="IMAGE_RESOURCES_KEY"
it's much graceful than bundle="IMAGE_RESOURCES_KEY/sample"

Comments

[James Mitchell]

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 ***

[Martin Cooper]

Reopening because I believe they are different problems.

STR-964 is about a problem with RequestUtils.present(), where it is looking
in the wrong scope for the message bundle.

STR-798 (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.

[Erwin Vervaet]

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 :)

[Erwin Vervaet]

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).

[Charles Fineman]

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).

[Ted Husted]

We should visit this in 1.2.x when the entire approach to modules might be
re-examined.

[David Graham]

*** STR-1288 has been marked as a duplicate of this bug. ***

[David Graham]

*** STR-1391 has been marked as a duplicate of this bug. ***

[David Graham]

*** STR-1412 has been marked as a duplicate of this bug. ***

[David Graham]

*** STR-1511 has been marked as a duplicate of this bug. ***

[Adam Kramer]

*** STR-1561 has been marked as a duplicate of this bug. ***

[Martin Cooper]

Reopening so that I can fix this pronto.

[Martin Cooper]

Fixed in the 20030716 nightly build. Also fixed in STRUTS_1_1_BRANCH.

[Deyan]

The fix, submitted by Martin in STRUTS_1_1_BRANCH
uses unconditionally the ModuleConfig instance without checking it for null.

However if it is not present in the request NPE occurs.

For instance ImgTag checks whether the ModuleConfig instance is null. Shouldn't
such check be added in RequestUtils also ?