[Exist-development] Changes to how in-memory fragments/xpaths work?

[Andrzej J. T. <an...@ch...>]

Guys:

It used to be that the following xquery code fragment:

	let $entry := jndi:search( ... )//dsml:dsml/dsml:directory-entries/dsml:entry

would return something like this:

	 <dsml:entry dn="uid=ted">
            <dsml:objectclass>
                <dsml:oc-value>top</dsml:oc-value>
                <dsml:oc-value>person</dsml:oc-value>
                <dsml:oc-value>posixAccount</dsml:oc-value>
                <dsml:oc-value>ravenUser</dsml:oc-value>
            </dsml:objectclass>
            <dsml:attr name="sn">
                <dsml:value>Seuss</dsml:value>
            </dsml:attr>
            <dsml:attr name="userPassword">
                <dsml:value>{SHA256}xxxxxxxx</dsml:value>
            </dsml:attr>
            <dsml:attr name="uidNumber">
                <dsml:value>5000</dsml:value>
 	    </dsml:attr>
	 </dsml:entry>

But with the latest trunk it returns an empty set!

Even though the document that is returned from the jndi:search() function is still (when I serialize
the output of the JNDI call)

     <dsml:dsml xmlns:dsml="http://www.dsml.org/DSML" dn="ou=users,o=xxx,dc=xxx,dc=com">
    	<dsml:directory-entries>
	   <dsml:entry dn="uid=ted">
            <dsml:objectclass>
                <dsml:oc-value>top</dsml:oc-value>
                <dsml:oc-value>person</dsml:oc-value>
                <dsml:oc-value>posixAccount</dsml:oc-value>
                <dsml:oc-value>ravenUser</dsml:oc-value>
            </dsml:objectclass>
            <dsml:attr name="sn">
                <dsml:value>Seuss</dsml:value>
            </dsml:attr>
            <dsml:attr name="userPassword">
                <dsml:value>{SHA256}xxxxxxxx</dsml:value>
            </dsml:attr>
            <dsml:attr name="uidNumber">
                <dsml:value>5000</dsml:value>
 	    </dsml:attr>
	  </dsml:entry>
    	</dsml:directory-entries>
    </dsml:dsml>

It seems that the handling and/or xpath matching to the root node has changed in trunk since
sometime last July.

The //dsml:dsml is not picking up the root node...it's like it's starting the search below the root
node and thus doesn't find the initial root node.

This was always a problem with in-memory fragments....you had to do a //root to get to the top level
on a fragment.  I'm having other symptoms that elsewhere in our application (we construct fragments
all over the place), that might be due to the same changed behaviour.

The problem is that if this behaviour has, in fact, been changed, it has broken a lot of our code in
a production healthcare system!

-- 
Andrzej Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com