PDA

View Full Version : Problem reading Regular Expressions using MessageSource



rthackst
Sep 1st, 2004, 07:19 AM
I am having difficulty reading regular expressions from a properties file using org.springframework.context.support.ResourceBundle MessageSource. The problem arises when the MessageSource interprets parts of the regex as asking for a substitution (like "{0}", "{1,date}", "{2,time}" within a message).

The regex I am using is: "^\d{1,3}$", which produces an IllegalArgumentException when read from the properties file.

Is there a way to tell MessageSource to ignore subsitution parameters? Or to hide them?

(I would assume that if you passed in null as the second parameter to getMessage(String, Object[], Locale), it would not look for substitution parameters.)

bpolka
Sep 1st, 2004, 11:17 AM
This has very little to do with Spring actually, but has everything to do with java.text.MessageFormat class, which spring delegates to when it comes to formatting of the resourced messages.

So given this info, I would suggest you to read the javadoc for the above mentioned class. My guess as to what you need, to get your regexp
^\d{1,3}$ to work, the following change
^\d'{'1,3'}'$ should probably do the trick. If not then just read the doc carefully and figure what you really need, since it is pretty detailed

HTH

rthackst
Sep 1st, 2004, 11:31 AM
Thanks Alex. It didn't occur to me that this was a wrapper for MessageFormat (too close to the trees to see the forest).

I'll check out the api.


Thanks.
Russell

bpolka
Sep 1st, 2004, 12:38 PM
This has very little to do with Spring actually, but has everything to do with java.text.MessageFormat class, which spring delegates to when it comes to formatting of the resourced messages.

So given this info, I would suggest you to read the javadoc for the above mentioned class. My guess as to what you need, to get your regexp
^\d{1,3}$ to work, the following change
^\d'{'1,3'}'$ should probably do the trick. If not then just read the doc carefully and figure what you really need, since it is pretty detailed

HTH