[
https://issues.apache.org/struts/browse/STR-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Benedict updated STR-2971:
-------------------------------
Component/s: Core
> one of validator.Resources.getActionMessage method does not respect message's
> "bundle" attribute
> ------------------------------------------------------------------------------------------------
>
> Key: STR-2971
> URL: https://issues.apache.org/struts/browse/STR-2971
> Project: Struts 1
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.2.9
> Environment: Struts 1.2.9, commons-validator 1.1.4
> Reporter: Christopher Schultz
> Assignee: Niall Pemberton
> Priority: Minor
> Fix For: 1.3.6
>
>
> I have a custom validator that uses the currently-loged-in user's date format
> preferences to validate date input. I use the following code to return error
> messages when there is a problem:
> if(error)
> {
> errors.add(field.getKey(),
> Resources.getActionMessage(request, va, field));
> return Boolean.FALSE;
> }
> The variables 'field' (commons.validator.Field), 'request',
> (HttpServletRequest) and 'va' (commons.validator.ValidatorAction) are all
> passed-in as parameters to this method, similar to other validateFoo(...)
> methods/classes.
> I recently separated my application resources (strings) into separate files
> based upon user role, to help manage the avalance of strings I had to deal
> with. I added a "bundle" attribute to my <msg> elements in my validation
> configuration file. This works for all of the stock validators, but not mine.
> I checked to see what the difference was between my code and the validators
> defined in struts.validator.FieldChecks, and they use this:
> errors.add(field.getKey(),
> Resources.getActionMessage(validator, request, va,
> field));
> Note the addition of that first parameter. I checked the code for these two
> different methods in the Resources class, and it appears that the latter will
> use the bundle attribute and get the appropriate message resource.
> I'm happy to change my code to use this other method -- it's no sweat to make
> that change. But I was suprised to see that this particular variety of the
> getActionMessage method did not respect the bundle setting, and also did not
> document that behavior.
> The "working" method uses the ValidatorAction parameter (missing in the
> method in question) to get the ServletContext where the MessageResources
> objects can be located. Since the HttpServletRequest is available in the
> "non-working" method, I believe this can still be achieved.
> Perhaps this "non-working" method should be deprecated in favor of the second
> method? Or, is there some historical reason why it needs to exist, and
> exhibit this behavior?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
