[
http://issues.apache.org/struts/browse/STR-2971?page=comments#action_38726 ]
Christopher Schultz commented on STR-2971:
------------------------------------------
I don't have the struts source code, and I would just add method javadoc, so
I'll just drop in this comment if you don't mind. How about something like
this, added to the method javadoc:
*
* Note that this method does not respect any bundle information stored
with the
* field's <msg< elements, and so localization does not work
properly. This method is
* deprecated for this reason, and you should use
* [EMAIL PROTECTED]
#getActionMessage(Validator,HttpServletRequest,ValidatorAction,Field)}
* instead.
Had I seen this comment in the Javadoc, I would have been able to solve this
problem myself without playing around too much.
If anyone objects to the deprecation of this method, we could always re-write
it to properly work with the bundle. In the "preferred" method, the Validator
argument is used for no other reason than to get the ServletContext. Since
/this/ method has access to the request, the ServletContext can be obtained
from there just as easily. Maybe there's a reason to prefer the one available
from the Validator object, but it seems like it's the same thing to me.
-chris
> one of validator.Resources.getActionMessage method does not respect message's
> "bundle" attribute
> ------------------------------------------------------------------------------------------------
>
> Key: STR-2971
> URL: http://issues.apache.org/struts/browse/STR-2971
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.9
> Environment: Struts 1.2.9, commons-validator 1.1.4
> Reporter: Christopher Schultz
> Priority: Minor
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
