Hi Daniel,
I am using the matches for checking with the Regular Expression.
Following is what happens :
For the regular Expression \d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}
"123" string fails. But for 123.45 passes. (123 fails but it actually should
have successfully validated since it correctly validated by the last OR
Expression \d{3}...so it should have been validated.
But when we use the Regular Expression
\d{3}[.]\d{2}[.]\d{2}|(\d{3}[.]\d{2}|\d{3})
"123" value actually is successfully validated.
I think u must have got the issue now. Is there anythis can be solved
rather?
Thanks Regds
Dev
-----Original Message-----
From: Daniel F. Savarese [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 4:42 PM
To: ORO Users List
Subject: Re: Pattern Regular Expressions: Consecutive ORs not handled
correctl y
In message <[EMAIL PROTECTED]>, Kayiti
Devan andam writes:
>I am using the jakarta-oro-2.0.5.jar for the validation of Strings with
>respect to the Regular Expression which we provide. In my case,
>whenever we have more than one OR's present in the Regular Expression,
>it doesn't work the way we think. It fails even though the String does
>maintain the Regular Expression Condition.
There are two things you need to do to get help in this matter. The first
is to upgrade to the latest version (2.0.8). The second is to write and
submit an example program that isolates and reproduces the problem.
>For example :
>Consecutive ORs in patterns are not handled correctly. The following
>expression:
>\d{3}[.]\d{2}[.]\d{2}|\d{3}[.]\d{2}|\d{3}
>Does not work as it should and throws the error. When you put
>parenthesis in to group the ORs like this:
>\d{3}[.]\d{2}[.]\d{2}|(\d{3}[.]\d{2}|\d{3})
>it works fine.
The two expressions mean different things. I don't know if you're using
contains or matches, but if you're using matches, read the docs for it
again. Remember, Perl expressions are greedy by default and match
alternations left to right, stopping on the leftmost match.
>I have seen a similar type bug being present in
>http://issues.apache.org/bugzilla/show_bug.cgi?id=9253
><http://issues.apache.org/bugzilla/show_bug.cgi?id=9253> for the 2.0.1
>version. I see that opened somewhere in May 2002 and hasn't been yet
closed.
That's a Xerces2 bug report. Also, it's not a bug for Perl but would be for
Awk. They match differently. For example, straight from the Perl perlre
man page:
when matching "foo|foot" against "barefoot", only the "foo"
part will match, as that is the first alternative tried, and it
successfully matches the target string.
For Awk, the "foot" part will match because it finds the longest match.
>Do anyone has any idea, whether this has been solved or not, and is
>there a fix available for this in new builds? and if not, is there any
>workaround, since in our cases we can't change change regular
>expression as such, as we do have quite a few schemas for it.
Without a reproducible test case, it's impossible to say whether you're
dealing with a "foo|foot" issue or something else.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
