Hi again Rhys,

Thanks for the additional info, but I do think we need something closer to
a stand-alone working example in order to determine if this is a bug.

As another reply to your e-mail alluded to, it would probably be a good
idea to look carefully at what happens between the first and second times
that your code gets executed.  Specifically, if you're modifying the DOM,
that will be a problem.

Kevin Cormier
Software Developer, XSLT Development
IBM Toronto Lab, D1-107
Phone: 905-413-5771
E-mail:  [EMAIL PROTECTED]


                                                                           
             "Rhys Parry"                                                  
             <[EMAIL PROTECTED]                                             
             .com>                                                      To 
                                       Kevin Cormier/Toronto/[EMAIL PROTECTED]  
   
             09/26/2006 04:52                                           cc 
             PM                        <xalan-j-users@xml.apache.org>      
                                                                   Subject 
                                       RE: Problem with recursive xpath    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Kevin,

Thanks for getting back so quickly.
First the questions:
>> but I'm assuming that's just a typo
Yes, this  is an email typo.  Note that changing the order of the nodes
does not effect the behaviour.  It is always the case that the first
element is successful and the 2nd element fails.  Always.

>>what version of Xalan are you using?
Latest and greatest.  From the Manifest:
Name: org/apache/xalan/
Comment: Main Xalan engine implementing TrAX/JAXP
Specification-Title: Java API for XML Processing
Specification-Vendor: Sun Microsystems Inc.
Specification-Version: 1.3
Implementation-Title: org.apache.xalan
Implementation-Version: 2.7.0
Implementation-Vendor: Apache Software Foundation
Implementation-URL: http://xml.apache.org/xalan-j/

Note that I also downloaded the dependencies with this build.

I think the issue is in the way that the DTMManagerDefault caches
pre-parsed xml.  But this is just a thought as I am not familiar with the
overall architecture.

>>Can you provide some more Java code showing how you are getting
converterAdditionalMappingNode?
The java code is an xmlbeans type object:
org.w3c.dom.Node converterAdditionalMappingNode =
nodeGroupType.getFieldMappingArray(someInt).getConverterAdditionalMapping().getDomNode();


I then do the xpath:
XPathFactory xpathfactory= XPathFactory.newInstance();
XPath xpath  = xpathfactory.newXPath();
//Note that the text() query is simplified behaviour.
String lookupConstant = (String)xpath.evaluate("text()",
converterAdditionalMappingNode, XPathConstants.STRING);

Now, the funny thing about this is that the code runs fine for the first
node always.  It is only when we unmarshal the second node that the error
occurs.  This is why I think that there is a caching issue.

The solution was for me to move the xpath expressions/objects up the class
call stack.  I am not super happy about this as I now have to cache an
xpath object, the XMLBeans object(s) as well as a document object created
using the XMLBeans objects raw xml files.  It works.  Which again leads me
to believe that the problem is some sort of cache issue.

The new code looks like:
Node converterAdditionalMappingNode =
((Node)stepConfigXPath.evaluate("//[EMAIL 
PROTECTED]'someID']/ConverterAdditionalMapping",
 configDocument, XPathConstants.NODE));

I then call (down in the call stack):
String lookupConstant = (String)xpath.evaluate("text()",
converterAdditionalMappingNode, XPathConstants.STRING);


This works everytime.

If this is not enough info please write back.  I can put something together
for you if you need but it will take me a few.   Right now I gotta get the
kids.

Again, thank you for the swift reply,
Rhys






-----Original Message-----
From: Kevin Cormier [mailto:[EMAIL PROTECTED]
Sent: September 26, 2006 4:24 PM
To: Rhys Parry
Cc: xalan-j-users@xml.apache.org
Subject: Re: Problem with recursive xpath


Hi Rhys,

I had a look at this problem, and the only mistake I noticed was that
content attribute of the first LookUpInfo element is missing the closing
quotation mark - but I'm assuming that's just a typo in  your e-mail.

It looks like this may be a bug in Xalan, but we'd need some more
information to reproduce it.  Can you provide some more Java code showing
how you are getting converterAdditionalMappingNode?  Ideally, put together
the simplest Java program and input XML file that shows this problem.  Also
- what version of Xalan are you using?

Thanks,

Kevin Cormier
Software Developer, XSLT Development
IBM Toronto Lab, D1-107
Phone: 905-413-5771
E-mail:  [EMAIL PROTECTED]



             "Rhys Parry"
             <[EMAIL PROTECTED]
             .com>                                                      To
                                       <xalan-j-users@xml.apache.org>
             09/26/2006 11:32                                           cc
             AM
                                                                   Subject
                                       Problem with recursive xpath










All,

I am getting the error: java.lang.RuntimeException: Could not resolve the
node to a handle
The error is very odd as it runs the first node successfully but throws an
exception on the second node, regardless of which node is executed ( I
moved the xml nodes around in the XML file).

Basically the program is parsing 2 files.  I file is the xml client data
(No problems even though I traverse the tree up and down) and the other is
an xml config file with xpath expressions in it.  An example of the xml I
am trying to run is (this is the xml config file):
<!-- Runs fine -->
<FieldMapping identifier="1.SubmissionType"
xpath="SubmissionTypeCode/text()"
converter="com.infoterra.grantium.service.integration.datamapper.converters.impl.LookupConverter">


             <ConverterAdditionalMapping>
                         <LookUpInfo constant="SF424_SUBMISSION_TYPE/>
             </ConverterAdditionalMapping>
</FieldMapping>

<!-- exception is thrown -->
<FieldMapping identifier="2.ApplicationType"
xpath="ApplicationTypeCode/text()"
converter="com.infoterra.grantium.service.integration.datamapper.converters.impl.LookupConverter">


             <ConverterAdditionalMapping>
                         <LookUpInfo constant="SF424_APPLICANT_TYPE"/>
             </ConverterAdditionalMapping>
</FieldMapping>

The java code that is calling the xpath is:
//Note that this is recreated for every node.  Is this part of the
problem?????
XPathFactory xpathfactory= XPathFactory.newInstance();

XPath xpath  = xpathfactory.newXPath();

//converterAdditionalMappingNode is the <ConverterAdditionalMapping> node
String lookupConstant = (String)xpath.evaluate("LookUpInfo/@constant",
converterAdditionalMappingNode, XPathConstants.STRING);


Note that I have XMLBean'ed the config file so that I can traverse it with
objects, however the <ConverterAdditionalMapping> node is supposed to be
client specific and therefore cannot be XMLBean'ed.

Why is there a problem with this?
The stack trace is:
Caused by: java.lang.RuntimeException: Could not resolve the node to a
handle
             at
org.apache.xml.dtm.ref.DTMManagerDefault.getDTMHandleFromNode(DTMManagerDefault.java:625)


             at
org.apache.xpath.XPathContext.getDTMHandleFromNode(XPathContext.java:220)
             at org.apache.xpath.XPath.execute(XPath.java:274)
             at org.apache.xpath.jaxp.XPathImpl.eval(XPathImpl.java:210)
             at
org.apache.xpath.jaxp.XPathImpl.evaluate(XPathImpl.java:275)
             at
com.infoterra.grantium.service.integration.datamapper.converters.impl.LookupConverter.convertSimpleData(LookupConverter.java:48)


             ... 27 more

I am trying to create a work around for now, but this will become a much
larger issue once the client configs become increasingly complicated.


Thanks in advance for any and all advice,
Rhys Parry
Product Development

Infoterra Inc. - Leadership in Enterprise Grants Management (EGM) Solutions
Phone #: 613-230-7890 Ext: 239
Fax #: 613-230-5243





Reply via email to