You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Luca Burgazzoli <lb...@gmail.com> on 2017/02/10 11:24:52 UTC
Camel Saxon and xslt
Hi everyone,
I've recently been working on camel-saxon and camel-xslt to enable
saxon specific stuffs in camel-xslt and this required some little
reflection hacks which could make it harder to detect potential api
breaks when updating saxon and could be problematic for java 9 if
saxon does not properly configure the modules system so I'm wondering
if it could make sense to create a saxon-xslt component (to be done
after 2.19) which inherit from xslt component and adds saxon specifc
stuffs without reflection hacks.
So with component:
- xslt --> you can still use saxon but can't confiugre saxon specific features
- saxon-xslt --> same as xslt but you can configure/use saxon specific features
Thoughts ?
---
Luca Burgazzoli
Re: Camel Saxon and xslt
Posted by Luca Burgazzoli <lb...@gmail.com>.
going to raise a ticket then
---
Luca Burgazzoli
On Fri, Feb 10, 2017 at 1:16 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Yeah it can make sense. It also ensures that users are not in doubt if
> they use saxon or not. Usually Saxon offers more advanced features
> that you dont have from the JDK.
>
> And maybe we can add something so users can install the commercial
> saxon and unlock xslt 3.0 functionality or what else is exclusive in
> their commercial product.
>
>
>
> On Fri, Feb 10, 2017 at 12:24 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
>> Hi everyone,
>>
>> I've recently been working on camel-saxon and camel-xslt to enable
>> saxon specific stuffs in camel-xslt and this required some little
>> reflection hacks which could make it harder to detect potential api
>> breaks when updating saxon and could be problematic for java 9 if
>> saxon does not properly configure the modules system so I'm wondering
>> if it could make sense to create a saxon-xslt component (to be done
>> after 2.19) which inherit from xslt component and adds saxon specifc
>> stuffs without reflection hacks.
>>
>> So with component:
>> - xslt --> you can still use saxon but can't confiugre saxon specific features
>> - saxon-xslt --> same as xslt but you can configure/use saxon specific features
>>
>> Thoughts ?
>>
>> ---
>> Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: Camel Saxon and xslt
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Yeah it can make sense. It also ensures that users are not in doubt if
they use saxon or not. Usually Saxon offers more advanced features
that you dont have from the JDK.
And maybe we can add something so users can install the commercial
saxon and unlock xslt 3.0 functionality or what else is exclusive in
their commercial product.
On Fri, Feb 10, 2017 at 12:24 PM, Luca Burgazzoli <lb...@gmail.com> wrote:
> Hi everyone,
>
> I've recently been working on camel-saxon and camel-xslt to enable
> saxon specific stuffs in camel-xslt and this required some little
> reflection hacks which could make it harder to detect potential api
> breaks when updating saxon and could be problematic for java 9 if
> saxon does not properly configure the modules system so I'm wondering
> if it could make sense to create a saxon-xslt component (to be done
> after 2.19) which inherit from xslt component and adds saxon specifc
> stuffs without reflection hacks.
>
> So with component:
> - xslt --> you can still use saxon but can't confiugre saxon specific features
> - saxon-xslt --> same as xslt but you can configure/use saxon specific features
>
> Thoughts ?
>
> ---
> Luca Burgazzoli
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2