[#XW-443] Validator parameters and message handled improperly

XWork

Validator parameters and message handled improperly

Created: 28/Nov/06 10:41 AM Updated: 18/Apr/08 04:49 AM

Component/s:

Validators

Affects Version/s:

None

Fix Version/s:

1.2.3

Environment:

« Hide

Windows XP, Tomcat 5.0.28, j2sdk1.4.2_10, xerces-J 2.6.2

Issue Links:

Related

This issue is related to:
	~~WW-1205~~ RegexFieldValidator cannot process wh...

Description

« Hide

When I use RegexFieldValidator with expression [a-zA-Z0-9_]* the string abc does not match this expression. After deeper analysis it turned out that the parser returns the expression as 3 org.apache.xerces.dom.TextImpl instances: "[a-zA-Z0-9_", "]" and "*". In com.opensymphony.xwork.validator.ValidatorFileParser class in method getTextValue - these 3 nodes are separated by MULTI_TEXTVALUE_SEPARATOR which gives in result expression: [a-zA-Z0-9_ ] * with white spaces in between. Hence my question: why there is a space used to separate the subsequent character data nodes? The xml parser is free to split the characters into many chunks - shouldn't they be just joint together?

The other problem regarding the parser is the message element. In addValidatorConfigs method it is assumed that the default message is the value of the first node from the children of message element. It is not true when the parser splits the data e.g. for me if I have <message>Please provide [1] number [2] code</message> in fact I get "Please provide [1" message.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Claus Ibsen - [31/Mar/07 04:44 PM ]

Michal can you provide details what version of XWork you are using?

In the 2.02 branch I can not reproduce that RegexFieldValidator would fail on matching [a-zA-Z0-9_]* with abc.

[ Permlink | « Hide ]

Rainer Hermanns - [06/Apr/07 01:35 PM ]

We need more infos to reproduce...
Feel free to reopen, if you can provide the requested infos.

[ Permlink | « Hide ]

Don Brown - [18/Jul/07 03:16 AM ]

Seems to be an issue with the Java 1.4 parser, which splits the text up into multiple text nodes. For some reason, XWork then was putting a space between the first two nodes. I removed that space insert.

[ Permlink | « Hide ]

Rene Gielen - [18/Jul/07 05:17 AM ]

Adding the Separator between lines was introduced with the fix for ~~WW-1205~~.

Deleting this has pros and cons. Pro, besides providing a workaround for the (weird!) parser issue, is that if you write a long regexp, with linebreaks for readability, the regexp will get messed up because of whitespaced mixed in.

On the con side, if users write something like
<![CDATA[
foo
bar
]]>
it will evaluate to one token (foobar), rather than two (which might be
expected).

I'm pretty unsure what is the right way here. Maybe we should make this
configurable, so that users can decide?

[ Permlink | « Hide ]

Michal Karwanski - [18/Jul/07 05:32 AM ]

Maybe you will accept the way I solve it for myself. The problem is that we should accumulate all the characters between the opening and closing tag. So I have changed com.opensymphony.xwork.util.DomHelper.StartHandler class in the following way:
- added private StringBuffer instance variable (cb),
- in startElement method cb variable is cleaned and then the invocation is forwarded to nextHandler,
- in characters method - characters given as a parameter are accumulated in cb - characters method is NOT forwarded to nextHandler
- in endElement method - if cb is not empty - nextHandler.characters method is invoked on the content in cb. The method nextHandler.endElement is anyway invoked after the conditional statement.

Is it OK or you can think of cases this solution might fail?

[ Permlink | « Hide ]

Jason Axtell - [18/Apr/08 04:49 AM ]

I just wanted to point out that the parser's behavior in splitting text into multiple nodes is not a bug. It is perfectly normal and allowed by the spec. Also, I don't think this issue should have been closed. The problems with both param and message text still exist in the head. The only sensible course here is to remove the extra space when concatenating multiple text nodes together in getTextValue. This will immediately fix the problem with param elements. To deal with message elements, we need to use the (modified) getTextValue method instead of getFirstChild on the messge nodes. Until that happens, validator xml is totally broken for me, and plenty of other folks too.