When validating a BPEL expression that contains an XPath expression containing "//", NetBeans blows up with the message
"java.lang.AssertionError: The index of axis 13 is out of possible values" (full stack trace attached, if I can figure
out how).  To reproduce the problem, have your BPEL contain an expression such as "$var1//foo" (a complete BPEL test
case is attached).

The problem is that the class org.netbeans.modules.xml.xpath.ext.impl.LocationStepImpl cannot deal with the XPath axis
named "descendant-or-self", usually abbreviated "//". The reason for this is that the XPath compiler (see
http://svn.apache.org/viewvc/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/Compiler.java?view=markup)
sends this axis as an integer, which the validator believes (incorrectly) is out of bounds.

The validator (see
http://deadlock.netbeans.org/fisheye/browse/~raw,r=1.2/netbeans/xml/xpath/ext/src/org/netbeans/modules/xml/xpath/ext/impl/LocationStepImpl.java)
contains the following code:

       assert axis < int2Axis.length : "The index of axis " + axis + " is out of possible values"; // NOI18N
        setAxis(int2Axis[axis - 1]);

This is the assertion that is failing, but this assertion is wrong. As you can see from the following statement, the
author knows that the incoming axis numbers start with 1. This means that the maximum legal value is int2Axis.length; so
the assertion should say "<=", not "<". As it happens, descendant-or-self is the value that the assertion incorrectly
excludes.

Incidentally, besides this assertion error, the class does not declare the XPath axes in the same order as the compiler.
This may cause other problems.

My workaround for this problem was to change from "//" to "/descendant::", since that was suitable for my needs.
Changing it to "descendant-or-self::" won't work, since it bumps into the same bug. If you really need this, you have to
write a Boolean expression.