Yes, here is to agree with Łukasz. XPath is not designed to generate XML documents. XPath let's you query an existing document to retrieve specific parts of it.
You may want to create an XSLT identity transform to turn each resulting Node into a proper document which can then include the XML declaration. Another idea is to insert a converBodyTo -> Document. That might do the trick too! On 27 Jan 2012, at 16:23, Chris Geer <ch...@cxtsoftware.com> wrote: > Thank you for the explanation. > > Chris > > 2012/1/27 Łukasz Dywicki <l...@code-house.org> > >> Hey Chris, >> Let me try to explain what happens under the hood. >> >> XSLT transformation requires an instance of javax.xml.transform.Source >> [1]. The result from the splitter is a org.w3c.dom.Node (or something >> similar). By default your node will be wrapped in DOMSource [2]. The >> explicit type conversion lets XSLT work with a Document instead of Node. >> Seems that xslt processor handles differently a Document instances and Node >> instances, but I don't know why. >> >> I guess that org.w3c.dom.Document is not supported as result type in >> XPathExpression [3] which is used for evaluation. Camel checks only if >> result can be assigned to org.w3c.dom.Node. >> >> Best regards, >> Łukasz Dywicki >> -- >> Code-House >> http://code-house.org >> >> [1] >> https://github.com/apache/camel/blob/trunk/camel-core/src/main/java/org/apache/camel/builder/xml/XsltBuilder.java#L409 >> [2] >> https://github.com/apache/camel/blob/trunk/camel-core/src/main/java/org/apache/camel/converter/jaxp/XmlConverter.java#L266 >> [3] >> http://docs.oracle.com/javase/1.5.0/docs/api/javax/xml/xpath/XPathExpression.html >> >> Wiadomość napisana przez Chris Geer w dniu 2012-01-26, o godz. 21:40: >> >>> Thank you guys. I added the converyBodyTo command instead of my crazy >>> setBody command and it seemed to work. I did have to change the attribute >>> to type vs javaType though. >>> >>> I wish I could explain why that was needed though. It seems odd that >> split >>> would change the data into something not compatible with xslt. I even >> tried >>> setting the resultType attribute on the split/xpath to >> org.w3c.dom.Document >>> and it didn't help. >>> >>> Chris >>> >>> On Thu, Jan 26, 2012 at 8:12 AM, Doug Douglass <douglass.d...@gmail.com >>> wrote: >>> >>>> Excellent suggestion Łukasz! >>>> >>>> Chris, have a look at >>>> http://camel.apache.org/xslt.html#XSLT-NotesonusingXSLTandJavaVersions, >>>> perhaps that will resolve your issue. For my quick unit test I'm using >>>> openjdk 1.6.0_22 (ArchLinux-6.b22_1.10.5-1-x86_64) and xalan 2.6.0 was >>>> already in my projects dependencies/classpath. >>>> >>>> Doug >>>> >>>> >>>> 2012/1/26 Łukasz Dywicki <l...@code-house.org> >>>> >>>>> I think you should not have any problems, the conversion is really >>>> simple. >>>>> After split statement you have a Node as body. For XSLT you need a >>>> Source. >>>>> Try adding this instead setBody >>>>> >>>>> <camel:convertBodyTo javaType="org.w3c.dom.Document" /> >>>>> >>>>> That should force conversion to document object and I belive fix your >>>>> problem. >>>>> >>>>> Best regards, >>>>> Łukasz Dywicki >>>>> -- >>>>> Code-House >>>>> http://code-house.org >>>>> >>>>> >>>>> Wiadomość napisana przez Chris Geer w dniu 2012-01-26, o godz. 01:36: >>>>> >>>>>> Doug, >>>>>> >>>>>> It doesn't make much sense to me either but I do know that with the >>>>> setBody >>>>>> command everything works and without it, it fails. If I run the XSLT >>>>>> against the same XML (save the XML to a file from the flow after the >>>>> split) >>>>>> in netbeans it works fine without the <?xml...?> but in camel it >> fails. >>>>>> >>>>>> Could the split be converting the output to a string? That would >>>> explain >>>>>> the problem. >>>>>> >>>>>> Chris >>>>>> >>>>>> On Wed, Jan 25, 2012 at 5:03 PM, Doug Douglass < >>>> douglass.d...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> Chris, >>>>>>> >>>>>>> I think the xml processing "fix" you've got there is a bit of >>>>> red-herring. >>>>>>> >>>>>>> The xml processing instruction should only be necessary if you are >>>>>>> converting the output of the xpath to a String prior to the xslt >>>>> endpoint, >>>>>>> whether directly or indirectly. Without any explicit conversion, the >>>>> output >>>>>>> of the xpath will be a Node object (DeferredElementNSImpl in my >> test), >>>>>>> which is converted to a Source via camel's built-in type conversion. >>>>>>> >>>>>>> I just set up a quick unit test with a route very similar to yours >> and >>>>>>> everything worked as I expected. Granted this test was in an existing >>>>>>> project using camel 2.7.3 (time to upgrade!). >>>>>>> >>>>>>> I suspect you're either running into a namespace problem[1] or your >>>>>>> templates XPaths aren't expecting Parcel (from your example) as the >>>> root >>>>>>> element. >>>>>>> >>>>>>> [1] >>>>>>> >>>>> >> http://camel.apache.org/xpath.html#XPath-Namespaceauditingtoaiddebugging >>>>>>> >>>>>>> Let us know more info (example XML and XSLT) if my suspicions are off >>>>> base. >>>>>>> >>>>>>> HTH, >>>>>>> Doug >>>>>>> >>>>>>> On Wed, Jan 25, 2012 at 3:35 PM, Chris Geer <ch...@cxtsoftware.com> >>>>> wrote: >>>>>>> >>>>>>>> Sorry, 2.8.3. >>>>>>>> >>>>>>>> On Wed, Jan 25, 2012 at 3:29 PM, Babak Vahdat >>>>>>>> <babak.vah...@swissonline.ch>wrote: >>>>>>>> >>>>>>>>> And what about the Camel version you use? >>>>>>>>> >>>>>>>>> Babak >>>>>>>>> >>>>>>>>> -- >>>>>>>>> View this message in context: >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> http://camel.465427.n5.nabble.com/Splitting-on-XML-Documents-tp5431032p5431531.html >>>>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
