[
http://opensource.atlassian.com/projects/hibernate/browse/HV-376?page=com...
]
Hardy Ferentschik edited comment on HV-376 at 2/7/11 4:05 AM:
--------------------------------------------------------------
The proposed solution by Kevin is to replace:
{code}private static final Pattern PATH_PATTERN = Pattern.compile(
"(\\w+)(\\[(\\w*)\\])?(\\.(.*))*" );{code}
by
{code}private static final Pattern PATH_PATTERN = Pattern.compile(
"(\\p{javaJavaIdentifierStart}\\p{javaJavaIdentifierPart}*)(\\[(\\w*)\\])?(\\.(.*))*"
);{code}
The latter works, because of pattern categories and the fact that {{Character}} methods of
the form _ismethodname_ which return boolean are valid categories. Considering this the
proposed solution seems to be correct.
However, there are concerns that not all JVM implementations implement these categories
properly. Obviously that would be against the spec, but I still would prefer that HV is
not failing in this case.
At the moment we have a regexp which is not 100% correct, but at least it works on all
JVMs (personally I think anyone using "€" and similar within method names should
be punished anyways). If switching to a more correct regular expression means that we
introduce problems for "reasonable" method names on some JVMs we maybe should
look at other solutions (or keep the current one).
was (Author: hardy.ferentschik):
The proposed solution by Kevin is to replace:
{code}private static final Pattern PATH_PATTERN = Pattern.compile(
"(\\w+)(\\[(\\w*)\\])?(\\.(.*))*" );{code}
by
{code}private static final Pattern PATH_PATTERN = Pattern.compile(
"(\\p{javaJavaIdentifierStart}\\p{javaJavaIdentifierPart}*)(\\[(\\w*)\\])?(\\.(.*))*"
);{code}
The latter works, because of pattern categories and the fact that {{Character}} methods of
the form _ismethodname_ which return boolean are valid categories. Considering this the
proposed solution seems to be correct.
However, there are concerns that not all JVM implementations implement these categories
properly. Obviously that would be against the spec, but I still would prefer that HV is
not failing in this case.
At the moment we have a regexp which is not 100% correct, but at least it works on all
JVMs (personally I think anyone using "€" and similar within method names should
be punished anyways). If switching to a more correct regular expression means that we
introduce problems for "reasonable" method names on some JVMs we maybe should
look at other solutions.
validateValue() and validateProperty() are too restrictive regarding
processable property names
-----------------------------------------------------------------------------------------------
Key: HV-376
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HV-376
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 4.1.0.Final
Reporter: Gunnar Morling
Assignee: Kevin Pollet
Priority: Minor
Fix For: 4.2.0.CR1
The methods Validator#validateValue() and Validator#validateProperty() expect the name of
a bean property, for which constraint validation should be performed.
Currently not all valid Java property (field/method) identifiers are supported here, as
the specified property name is processed in PathImpl with a regular expression, that
matches only the word character class (A-Za-z0-9_), causing the evaluation of uncommon but
yet valid property names such as the following ones to fail:
* private String höchstBetrag; // German Umlaute such as "ö" are allowed in
Java identifiers
* private String €Amount; // some currency signs such as "€" are allowed,
sigh
* private String höchst\u00f6Betrag; // specifying letters such as "ö" using
Unicode is allowed
Trying to do so results in the following exception:
{code:java}
java.lang.IllegalArgumentException: Unable to parse property path ö
at org.hibernate.validator.engine.PathImpl.parseProperty(PathImpl.java:216)
at org.hibernate.validator.engine.PathImpl.createPathFromString(PathImpl.java:64)
at org.hibernate.validator.engine.ValidatorImpl.validateValue(ValidatorImpl.java:152)
{code}
More information on the identifiers allowed in the Java language can be found in [JLS,
chapter
3.8|http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8].
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira