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. > >>>>>>> > >>>>>> > >>>>> > >>> > >>> > >> > >
