Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313992

Summary: [xpath] [patch] XPath evaluation does not show results which are atomic
Product: [WebTools] WTP Source Editing Reporter: Jesper Moller <jesper>
Component: wst.htmlAssignee: Jesper Moller <jesper>
Status: RESOLVED FIXED QA Contact: David Carver <d_a_carver>
Severity: major    
Priority: P3 CC: neil.hauge, thatnitind
Version: 3.2Flags: thatnitind: pmc_approved? (david_williams)
thatnitind: pmc_approved? (raghunathan.srinivasan)
thatnitind: pmc_approved? (naci.dai)
thatnitind: pmc_approved? (deboer)
neil.hauge: pmc_approved+
thatnitind: pmc_approved? (kaloyan)
d_a_carver: review+
thatnitind: review+
Target Milestone: 3.2.1   
Hardware: All   
OS: All   
Whiteboard: PMC_approved
Attachments:
Description Flags
Patch which fixes the display of non-DOM-node results (i.e. atomic values) in the XPath view
none
Updated patch with tests
none
mylyn/context/zip none

Description Jesper Moller CLA 2010-05-21 18:39:24 EDT 
WTP 3.2 RC2 build (retrieved as wst-sdk-buildrepo-S-3.2.0RC2-20100520232028)

When evaluating XPath, only nodesets are shown in the result view, not atomic values such as strings and the like. This is the same for XPath1 and XPath2 evaluation.
The bug: For XPath1, the result is silently dropped. For XPath2, a non-node result causes an NPE exception in the Error Log.

The fix: The attached patch fixes this and adds some extra nullchecks where applicable. For XPath1, the patch checks for results which cannot be returned as a NodeList, and returns these as a String instead. For  XPath2 evaluation, the results are either used as nodes or as string values, since all atomic values in XPath has a string_value().

The patch is quite local.
Comment 1 Jesper Moller CLA 2010-05-21 18:41:40 EDT 
Created attachment 169566 [details]
Patch which fixes the display of non-DOM-node results (i.e. atomic values) in the XPath view
Comment 2 Jesper Moller CLA 2010-06-01 03:04:40 EDT 
Moved component for this one as well.
Comment 3 Jesper Moller CLA 2010-06-01 03:06:01 EDT 
And reassigned to the xsl-inbox...
Comment 4 David Carver CLA 2010-06-01 10:38:35 EDT 
Add assigning to Jesper... :)
Comment 5 Jesper Moller CLA 2010-06-24 00:50:55 EDT 
This one should go into 3.2.1 as well - please review.
Comment 6 David Carver CLA 2010-06-24 11:48:24 EDT 
Looks good to me...
Comment 7 Jesper Moller CLA 2010-07-01 18:59:13 EDT 
* Explain why you believe this is a stop-ship defect.
Without this, an ugly exception is thrown into the Event Log. I really hate those, it makes us look bad.

* Is there a work-around? No - valid XPath expressions fail.

* How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?
I have tested the combinations thoroughly, in the XPath View, manually. There will be a JUnit test attached within the next 24 hours.

* Give a brief technical overview:
For both XPath1.0 and XPath2, the existing code did not account for the case where an expression did not yield a result which was not a DOM node. This code handles this case, by converting any non-node result into a string and showing that, for both XPath 1.0 and 2.

* Who has reviewed this fix?
David Carver

* What is the risk associated with this fix?
Quite low, since it only adds a simple solution to a code path that would otherwise fail.

But ... should this be reviewd by Project Lead Nitin before PMC review?
Comment 8 Nitin Dahyabhai CLA 2010-07-02 15:02:10 EDT 
Consider it approved by me.  PMC review questionnaire in comemnt 7.
Comment 9 Jesper Moller CLA 2010-07-02 19:01:45 EDT 
Created attachment 173334 [details]
Updated patch with tests

As promised, a test which will test the fix.
Also fixed copyrights.
Comment 10 Jesper Moller CLA 2010-07-02 19:01:47 EDT 
Created attachment 173335 [details]
mylyn/context/zip
Comment 11 Jesper Moller CLA 2010-07-02 19:27:14 EDT 
Relased to 3_2_Maintenance as per PMC review as v201007022358, and to HEAD v201007022359.