[
https://issues.apache.org/jira/browse/JXPATH-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046117#comment-13046117
]
Matt Benson edited comment on JXPATH-151 at 6/8/11 6:18 PM:
------------------------------------------------------------
Setting up a similar map to what you have described, and accessing via a bean
property I still found the errors you describe. This issue was fairly
difficult to triage, but my final diagnosis is that it is indicative of a bug.
It is interesting to note that the {{value\[@name='a'\] != value\[@name='b\]}}
approach succeeded, and of course the two approaches _should_ yield equivalent
results for any key conforming to {{QName}} restrictions. I would still
consider it dangerous to depend on {{null}} values in JXPath, however. For
example, if you add a mapping of {{"d":0}} to your map, you will find that
{{value\[@name='d'\] = value\[@name='b'\]}} because the fact that {{d}} refers
to a numeric type forces the conversion of {{b}}'s {{null}} value to a number,
{{0.0}}. XPath is tricky this way, and JXPath, dealing with types unknown to
the XPath specification only becomes trickier.
Having said all that, and to return to the issue at hand, I found that certain
existing JXPath tests assert that it should be possible to get a {{null}} value
from the expression {{bean.nullProperty}}, but that iterating pointers from the
expression {{bean.nullProperty\[1\]}} should yield no results. But this
assigns a Java-centric meaning to XPath's {{\[1\]}} test, and it is my judgment
that this is overstepping given that Javadoc for relevant methods states that
non-Collection items should be treated as having length 1. Making the
conscious decision to _change_ an existing unit test is not a decision to make
lightly, but in this case my opinion is that it is warranted.
was (Author: mbenson):
Setting up a similar map to what you have described, and accessing via a
bean property I still found the errors you describe. This issue was fairly
difficult to triage, but my final diagnosis is that it is indicative of a bug.
It is interesting to note that the {{value\[@name='a'\] != value\[@name='b\]}}
approach succeeded, although I would still consider it dangerous to depend on
{{null}} values in JXPath. For example, if you add a mapping of {{"d":0}} to
your map, you will find that {{value\[@name='d'\] = value\[@name='b'\]}}
because the fact that {{d}} refers to a numeric type forces the conversion of
{{b}}'s {{null}} value to a number, {{0.0}}. XPath is tricky this way, and
JXPath, dealing with types unknown to the XPath specification only becomes
trickier.
Having said all that, and to return to the issue at hand, I found that certain
existing JXPath tests assert that it should be possible to get a {{null}} value
from the expression {{bean.nullProperty}}, but that iterating pointers from the
expression {{bean.nullProperty\[1\]}} should yield no results. But this
assigns a Java-centric meaning to XPath's {{\[1\]}} test, and it is my judgment
that this is overstepping given that Javadoc for relevant methods states that
non-Collection items should be treated as having length 1. Making the
conscious decision to _change_ an existing unit test is not a decision to make
lightly, but in this case my opinion is that it is warranted.
> null handling is inconsistent
> -----------------------------
>
> Key: JXPATH-151
> URL: https://issues.apache.org/jira/browse/JXPATH-151
> Project: Commons JXPath
> Issue Type: Bug
> Affects Versions: 1.3
> Environment: windows oracle jvm 1.6_25
> Reporter: Johannes Stelzer
> Priority: Blocker
>
> Comparing a vaule to null using unequals (\!=) yields false!
> {noformat}
> Map<String, Integer> m = new HashMap<String, Integer>();
> m.put("a", 1);
> m.put("b", null);
> m.put("c", 1);
> JXPathContext c = JXPathContext.newContext(m);
> System.out.println(c.getValue("a != b") + " should be true");
> System.out.println(c.getValue("a != c") + " should be false");
> System.out.println(c.getValue("a = b") + " should be false");
> System.out.println(c.getValue("a = c") + " should be true");
> System.out.println(c.getValue("not(a = b)") + " should be true");
> System.out.println(c.getValue("not(a = c)") + " should be false");
> {noformat}
> Output using 1.3:
> {color:red} false should be true{color}
> false should be false
> false should be false
> true should be true
> true should be true
> false should be false
> In 1.2 it works correctly!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
