camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Saxon and saxon9he
Date Fri, 16 Nov 2012 11:33:53 GMT
Do you think I should create a JIRA concerning the camel-saxon feature not
working on a pure Karaf?

/Bengt


2012/11/16 Bengt Rodehav <bengt@rodehav.com>

> OK, if that's the case then I'm "already there" since I use Saxon for
> xpath as well.
>
> Thanks,
>
> /Bengt
>
>
> 2012/11/16 Claus Ibsen <claus.ibsen@gmail.com>
>
>> On Fri, Nov 16, 2012 at 8:56 AM, Bengt Rodehav <bengt@rodehav.com> wrote:
>> > Hello Christian.
>> >
>> > Thanks for your remarks. However, I did try using the camel-saxon
>> feature
>> > (first thing I did) but it doesn't work when running under pure Karaf.
>> It
>> > probably works under ServiceMix (haven't tested that) but I have my own
>> > custom Karaf+Camel distribution.
>> >
>> > I'm not 100% sure what is wrong but first of all an XmlResolver is
>> needed
>> > which is why I need to install
>> org.apache.servicemix.bundles.xmlresolver.
>> > It seems like the camel-saxon features assumes that this is present. I
>> > think this bundle should be added to the camel-saxon feature since the
>> > feature shouldn't assume that you are running in ServiceMix. It should
>> only
>> > assume a standard Karaf.
>> >
>> > Also, I can't get it to work with version 9.3.0.11_2
>> > of org.apache.servicemix.bundles.saxon due to "No XPathFctory
>> > implementation found for the object model:
>> http://saxon.sf.net/jaxp/xpath/om".
>> > If I change to version 9.4.0.4_1 it works.
>> >
>> > Perhaps the Camel feature descriptors are not adapted for Karaf 2.3.0?
>> Or
>> > they are not tested in pure Karaf but only in ServiceMix (this is what I
>> > think).
>> >
>> > Regarding xquery vs xpath that's very interesting. My use case doesn't
>> need
>> > anything more advanced than xpath and I (falsely?) assumed that the
>> least
>> > advanced (xpath) would give me the best performance. It seems very
>> > illogical that the more advanced xquery would perform better. I will try
>> > your suggestion though.
>> >
>>
>> I doubt that too, its just that xquery is implemented by Saxon. And
>> Saxon is faster than what comes default from the JDK. So when people
>> switch to xquery the get the faster Saxon.
>>
>>
>> > Thanks,
>> >
>> > /Bengt
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2012/11/15 Christian Müller <christian.mueller@gmail.com>
>> >
>> >> Hi Bengt!
>> >>
>> >> Two remarks:
>> >> You can leverage on the camel-saxon feature [1] to manage all the
>> >> dependencies saxon need.
>> >> And you could try using xquery instead of xpath [2]. It should be
>> faster.
>> >>
>> >> [1]
>> >>
>> >>
>> https://svn.apache.org/repos/asf/camel/trunk/platforms/karaf/features/src/main/resources/features.xml
>> >> [2]
>> >>
>> >>
>> https://github.com/muellerc/esbperformance/blob/esbperformance-1.1.x/servicemix-osgi/cbr/src/main/resources/META-INF/spring/bundle-context.xml
>> >>
>> >> Best,
>> >> Christian
>> >>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message