Problem with recursive xpath 2006-09-26 - By Rhys Parry
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("/
/FieldMapping[@(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:kcormier@(protected)]
Sent: September 26, 2006 4:24 PM
To: Rhys Parry
Cc: xalan-j-users@(protected)
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: kcormier@(protected)
"Rhys Parry"
<rparry@(protected)
.com> To
<xalan-j-users@(protected)>
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/@(protected)",
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
|
|
