RE: [Springframework-developer] purpose of code in Errors.rejectValue()

[<jue...@we...>]

> I'm not so keen on this. I think when throwing an exception,=20
> code should only provide an error code. It won't necessarily=20
> know about how messages are
> resolved: this is a presentation issue.

I agree completely. Message resolution should happen at model =
aggregation or view rendering time.

> Maybe a compromise would be to have a fallback approach, in=20
> which the ErrorResolver implementation, if it failed to look=20
> up a message for an exception's error code, looked for a=20
> ResourceBundle called messages.properties in the same package=20
> as the exception. I think this would allow what you propose,=20
> but still permit the use of an override at framework level.

I don't really like such a fallback. Hardcoding to a resource bundle =
here would kind of violate Spring's message source approach. What about =
allowing for a dedicated error message source, configured via the =
application context and specified by the error resolver?

> Btw, the present approach isn't limited to a single message=20
> source: MessageSources nest.

At least in theory... ;-)

Seriously, I've just tried it, and it didn't work with =
ResourceBundleMessageSources, due to a ResourceBundle's =
MissingResourceException going up to AbstractNestingMessageSource and =
being converted to NoSuchMessageException there.

A little fix in ResourceBundleMessageSource's resolve method, namely =
catching the MissingResourceException and converting it to a null return =
value, corrects this. I've just committed it - now MessageSources do =
indeed nest! :-)

Juergen