Community
Participate
Working Groups
During testing of M7, I discovered that the XPath2 processor now calls getNamespaceURI() with a null prefix when looking up function names. This is a regression and API violation. The NamespaceContext provided by the StaticContextBuilder doesn't object to this, but in the UI (the XPath view), this causes an error whenever resolving a function without a prefix.
Created attachment 195266 [details] Patch for this issue This patch cleans up the calls into StaticContext re. namespace contexts
Created attachment 195280 [details] Tests The new test in TestBugs addresses this feature. The other changes clean up the test preconditions which were not quite right,
Could you review this, I'm trying to get this into RC1, since it breaks the XPath view for some common cases? The description is slightly wrong, since it's local scopes ("for each a$ in ...") which causes the NPE, not function names.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. It's a regression, and it gives an ugly NPE in the error log * Is there a work-around? If so, why do you believe the work-around is insufficient? Only workaround is to qualify variable names in the XPath editor and set up a namespace, which is cumbersome. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested manually by me (Mac + WinXP), tested by the 8000+ test cases, plus a new one I added especially for this * Give a brief technical overview. Who has reviewed this fix? The current code resolved the namespace prefix for variables in several different places, and one place forgot to guard or missing namespaces, which is marked internally by null. David Carver is reviewing this currently. * What is the risk associated with this fix? Quite low - it's a single class, and the new code is clearer and has less duplicated logic.
Looks good.
Committed, tagged and released
