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
