You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2011/11/21 08:45:33 UTC
Unit test failure on trunk in camel-saxon
Hi
We have a failure on trunk in 1 unit test in camel-saxon
Failed tests:
testInvalidStylesheet(org.apache.camel.component.xslt.SaxonInvalidXsltFileTest):
Should have thrown an exception due XSL compilation error
https://builds.apache.org/job/Camel.trunk.fulltest/org.apache.camel$camel-saxon/559/testReport/
It's due some recent improvement to load the stylesheet from a header.
If anyone got cycles to look into this today or tomorrow that would be great.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
Hi,
https://issues.apache.org/jira/browse/CAMEL-4700
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5010536.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
So that by [1] I simply mimicked the same changes done on unit-tests by [2]
[1] https://issues.apache.org/jira/browse/CAMEL-4700
[2] https://issues.apache.org/jira/browse/CAMEL-4689
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5010683.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
Hi Willem,
completely agree on your proposal, and looking at the changes on the
existing unit-tests by [1], that's [2] & [3] that "fail-fast" behaviour
seems to be gone away.
[1] http://svn.apache.org/viewvc?rev=1202819&view=rev
[2]
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/component/xslt/InvalidXsltFileTest.java?r1=1202819&r2=1202818&pathrev=1202819
[3]
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/java/org/apache/camel/component/xslt/XsltFileNotFoundTest.java?r1=1202819&r2=1202818&pathrev=1202819
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5010674.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
Great! now the referee on the Wiki [1] is also up-to-date as well.
[1] https://cwiki.apache.org/confluence/display/CAMEL/Building (@ the line
"You can also find some helpful notes on usage here." )
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5015827.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by Jon Anstey <ja...@gmail.com>.
Oh wow, that is an old blog post :) I've updated it to point to the new
URLs. Thanks for letting me know!
Cheers,
Jon
On Tue, Nov 22, 2011 at 12:08 PM, bvahdat <ba...@swissonline.ch>wrote:
> Hi Jon,
>
> Thanks a lot for your commitment on this and bringing that behaviour back
> into the play.
>
> Other than this I've got another concern which I would really appreciate if
> you could take a look at:
>
> As you can see in [1] the links on your old blog entry seem to point to
> out-dated eclipse templates (I assume that was at the time before camel
> went
> TLP). For example the second "here" link there points to a file with the
> following content:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Root>
> <Child>
> <SubChild>AAA</SubChild>
> <SubChild>BBB</SubChild>
> </Child>
> </Root>
>
> Would it be possible for you to make those two "here" & "here" links inside
> that blog entry point to [2] & [3].
>
> [1]
>
> http://camel.465427.n5.nabble.com/converting-form-JAVA-DSL-to-Spring-DSL-tp5011220p5012896.html
> [2]
>
> https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/camel_java_templates.xml
> [3]
>
> https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/camel_xml_templates.xml
>
> Babak
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5013883.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
Hi Jon,
Thanks a lot for your commitment on this and bringing that behaviour back
into the play.
Other than this I've got another concern which I would really appreciate if
you could take a look at:
As you can see in [1] the links on your old blog entry seem to point to
out-dated eclipse templates (I assume that was at the time before camel went
TLP). For example the second "here" link there points to a file with the
following content:
<?xml version="1.0" encoding="UTF-8"?>
<Root>
<Child>
<SubChild>AAA</SubChild>
<SubChild>BBB</SubChild>
</Child>
</Root>
Would it be possible for you to make those two "here" & "here" links inside
that blog entry point to [2] & [3].
[1]
http://camel.465427.n5.nabble.com/converting-form-JAVA-DSL-to-Spring-DSL-tp5011220p5012896.html
[2]
https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/camel_java_templates.xml
[3]
https://svn.apache.org/repos/asf/camel/trunk/etc/eclipse/camel_xml_templates.xml
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5013883.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Yes, I saw. Looks good. Thanks,
Hadrian
On 11/22/2011 10:15 AM, Jon Anstey wrote:
> Yeah, I get that. Thanks for the feedback. FYI I committed the changes I
> proposed before so we should be all set with this now.
>
> Cheers,
> Jon
>
> On Tue, Nov 22, 2011 at 11:41 AM, Hadrian Zbarcea<hz...@gmail.com>wrote:
>
>> Good, so I assume we agree that:
>>
>> Pros:
>> 1. It gives confidence that when a message comes with no header defined
>> there will be a xslt stylesheet to use, i.e. there is high confidence in
>> the endpoint configuration.
>>
>> Cons:
>> 1. This doesn't say much about the quality of the stylesheet, i.e. the
>> results of xslt processing are the ones expected.
>> 2. Forces you to have the xslt stylesheet provisioned on startup, way
>> before the first message.
>>
>> I assume the majority of use cases use one stylesheet configured in the
>> uri, so the inconsistency is not that relevant.
>>
>> To be clear, my problem is not with implementing this behavior, but with
>> introducing new options to support this behavior. Camel is unnecessarily
>> too complicated as it is. If you think that can be done without introducing
>> new options, go for it.
>>
>> I hope this clarifies it,
>> Hadrian
>>
>>
>>
>> On 11/22/2011 09:53 AM, Jon Anstey wrote:
>>
>>> Replace "valid" with "file exists and can be compiled without error";
>>> essentially putting back in the old startup behavior while keeping the new
>>> behavior of checking for an XSLT via header on each exchange.
>>>
>>> On Tue, Nov 22, 2011 at 11:20 AM, Hadrian Zbarcea<hz...@gmail.com>**
>>> wrote:
>>>
>>> No. Define valid. Read my previous post.
>>>> Hadrian
>>>>
>>>>
>>>> On 11/22/2011 09:27 AM, Jon Anstey wrote:
>>>>
>>>> Hey guys,
>>>>>
>>>>> Just seeing this thread now (was off for a few days...), of course I
>>>>> only
>>>>> ran the camel-core tests before committing ;) I'm going to change the
>>>>> behavior to fail fast again such that if you want to provide XSLT via
>>>>> header, you will need to also specify a valid XSLT on the URI. So, it
>>>>> will
>>>>> be useful for the case where you want to override the XSLT on the URI
>>>>> with
>>>>> one provided via header. Everyone OK with that?
>>>>>
>>>>> Cheers,
>>>>> Jon
>>>>>
>>>>> On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea<hz...@gmail.com>**
>>>>> wrote:
>>>>>
>>>>> -1. Why?
>>>>>
>>>>>>
>>>>>> Camel got extremely complicated already with a lot of useless features
>>>>>> and
>>>>>> options. The way it is now is consistent with the Camel principles:
>>>>>> * use what's in the header
>>>>>> * if not, use the endpoint configuration provided via uri
>>>>>> * if that is not present used hardcoded configuration values.
>>>>>>
>>>>>>
>>>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>>>
>>>>>>> error up front, which can be very important to know.
>>>>>>>
>>>>>>> It is important to know, that's for sure. Reason why users should
>>>>>> test
>>>>>> their stylesheets before putting them in production. In addition to
>>>>>> that,
>>>>>> the fact that a style compiles doesn't mean that it will behave as
>>>>>> expected
>>>>>> when processing a message. Thats guaranteed (as much as possible) by
>>>>>> knowing your messages and doing thorough testing before going in
>>>>>> production, not by loading the stylesheet at endpoint creation.
>>>>>>
>>>>>> Failing fast is a good principle, we should always try for that, but
>>>>>> this
>>>>>> is not what this proposal is achieving.
>>>>>>
>>>>>> My $0.02,
>>>>>> Hadrian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>>>>>>
>>>>>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<babak.vahdat@****swisson**
>>>>>>
>>>>>>> line.ch<http://swissonline.ch>**<babak.vahdat@**swissonline.ch**<
>>>>>>> babak.vahdat@swissonline.ch>
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>>>
>>>>>>>> looking at the build of this morning [1] the test failure issue is
>>>>>>>> now
>>>>>>>> fixed, however like Willem I think the pre-existing fail-fast
>>>>>>>> behaviour
>>>>>>>> should be brought back as it used to be there. This however would
>>>>>>>> require
>>>>>>>> another JIRA-Ticket than [2] having the corresponding description /
>>>>>>>> goal.
>>>>>>>>
>>>>>>>>
>>>>>>>> +1
>>>>>>>
>>>>>>> However I think we could consider adding a new option to
>>>>>>> ResourceEndpoint to support to control if the resource should
>>>>>>> be loaded on startup or lazy loaded upon first request. The former has
>>>>>>> fail fast, and the latter would defer loading the resource once its
>>>>>>> demanded, but with the penalty of compiling/parsing the template
>>>>>>> overhead.
>>>>>>>
>>>>>>> Then the option could be default as the old behavior of loading the
>>>>>>> resource on startup.
>>>>>>> Wonder what a good name for such an option would be?
>>>>>>> - lazyLoadResource
>>>>>>> - loadResourceOnStartup
>>>>>>> ??
>>>>>>>
>>>>>>> The mina component have a laztCreateSession option, so the lazy name
>>>>>>> could be a good name
>>>>>>> http://camel.apache.org/mina
>>>>>>>
>>>>>>>
>>>>>>> Fail fast is IMHO especially needed to allow people to know something
>>>>>>> is wrong. We have seen many issues with loading resources in classpath
>>>>>>> on various servers of all sorts, and the likes of Java WebStart,
>>>>>>> JBoss, OSGi etc.
>>>>>>>
>>>>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>>>> error up front, which can be very important to know.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://builds.apache.org/job/******Camel.trunk.fulltest/564/<https://builds.apache.org/job/****Camel.trunk.fulltest/564/>
>>>>>>> <**https://builds.apache.org/job/****Camel.trunk.fulltest/564/<https://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>>>>>>
>>>>>>> <ht**tps://builds.apache.org/**job/**Camel.trunk.fulltest/**564/<http://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>>>>> <https://builds.apache.**org/job/Camel.trunk.fulltest/**564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> [2] https://issues.apache.org/******jira/browse/CAMEL-4700<https://issues.apache.org/****jira/browse/CAMEL-4700>
>>>>>>>> <https:/**/issues.apache.org/**jira/**browse/CAMEL-4700<https://issues.apache.org/**jira/browse/CAMEL-4700>
>>>>>>>>>
>>>>>>>> <https:/**/issues.apache.org/**jira/**browse/CAMEL-4700<http://issues.apache.org/jira/**browse/CAMEL-4700>
>>>>>>>> <https**://issues.apache.org/jira/**browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Babak
>>>>>>>
>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context: http://camel.465427.n5.nabble.******
>>>>>>>> com/Unit-test-failure-on-******trunk-in-camel-saxon-****
>>>>>>>> tp5009713p5012820.html<http://****camel.465427.n5.nabble.com/****<http://camel.465427.n5.nabble.com/**>
>>>>>>>> Unit-test-failure-on-trunk-in-****camel-saxon-**
>>>>>>>> tp5009713p5012820.**html<http:**//camel.465427.n5.nabble.com/**
>>>>>>>> Unit-test-failure-on-trunk-in-**camel-saxon-tp5009713p5012820.**html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>> Hadrian Zbarcea
>>>>>> Principal Software Architect
>>>>>> Talend, Inc
>>>>>> http://coders.talend.com/
>>>>>> http://camelbot.blogspot.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>> Hadrian Zbarcea
>>>> Principal Software Architect
>>>> Talend, Inc
>>>> http://coders.talend.com/
>>>> http://camelbot.blogspot.com/
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
>>
>
>
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: Unit test failure on trunk in camel-saxon
Posted by Jon Anstey <ja...@gmail.com>.
Yeah, I get that. Thanks for the feedback. FYI I committed the changes I
proposed before so we should be all set with this now.
Cheers,
Jon
On Tue, Nov 22, 2011 at 11:41 AM, Hadrian Zbarcea <hz...@gmail.com>wrote:
> Good, so I assume we agree that:
>
> Pros:
> 1. It gives confidence that when a message comes with no header defined
> there will be a xslt stylesheet to use, i.e. there is high confidence in
> the endpoint configuration.
>
> Cons:
> 1. This doesn't say much about the quality of the stylesheet, i.e. the
> results of xslt processing are the ones expected.
> 2. Forces you to have the xslt stylesheet provisioned on startup, way
> before the first message.
>
> I assume the majority of use cases use one stylesheet configured in the
> uri, so the inconsistency is not that relevant.
>
> To be clear, my problem is not with implementing this behavior, but with
> introducing new options to support this behavior. Camel is unnecessarily
> too complicated as it is. If you think that can be done without introducing
> new options, go for it.
>
> I hope this clarifies it,
> Hadrian
>
>
>
> On 11/22/2011 09:53 AM, Jon Anstey wrote:
>
>> Replace "valid" with "file exists and can be compiled without error";
>> essentially putting back in the old startup behavior while keeping the new
>> behavior of checking for an XSLT via header on each exchange.
>>
>> On Tue, Nov 22, 2011 at 11:20 AM, Hadrian Zbarcea<hz...@gmail.com>**
>> wrote:
>>
>> No. Define valid. Read my previous post.
>>> Hadrian
>>>
>>>
>>> On 11/22/2011 09:27 AM, Jon Anstey wrote:
>>>
>>> Hey guys,
>>>>
>>>> Just seeing this thread now (was off for a few days...), of course I
>>>> only
>>>> ran the camel-core tests before committing ;) I'm going to change the
>>>> behavior to fail fast again such that if you want to provide XSLT via
>>>> header, you will need to also specify a valid XSLT on the URI. So, it
>>>> will
>>>> be useful for the case where you want to override the XSLT on the URI
>>>> with
>>>> one provided via header. Everyone OK with that?
>>>>
>>>> Cheers,
>>>> Jon
>>>>
>>>> On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea<hz...@gmail.com>**
>>>> wrote:
>>>>
>>>> -1. Why?
>>>>
>>>>>
>>>>> Camel got extremely complicated already with a lot of useless features
>>>>> and
>>>>> options. The way it is now is consistent with the Camel principles:
>>>>> * use what's in the header
>>>>> * if not, use the endpoint configuration provided via uri
>>>>> * if that is not present used hardcoded configuration values.
>>>>>
>>>>>
>>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>>
>>>>>> error up front, which can be very important to know.
>>>>>>
>>>>>> It is important to know, that's for sure. Reason why users should
>>>>> test
>>>>> their stylesheets before putting them in production. In addition to
>>>>> that,
>>>>> the fact that a style compiles doesn't mean that it will behave as
>>>>> expected
>>>>> when processing a message. Thats guaranteed (as much as possible) by
>>>>> knowing your messages and doing thorough testing before going in
>>>>> production, not by loading the stylesheet at endpoint creation.
>>>>>
>>>>> Failing fast is a good principle, we should always try for that, but
>>>>> this
>>>>> is not what this proposal is achieving.
>>>>>
>>>>> My $0.02,
>>>>> Hadrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>>>>>
>>>>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<babak.vahdat@****swisson**
>>>>>
>>>>>> line.ch<http://swissonline.ch>**<babak.vahdat@**swissonline.ch**<
>>>>>> babak.vahdat@swissonline.ch>
>>>>>>
>>>>>>
>>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>>>
>>>>>>> looking at the build of this morning [1] the test failure issue is
>>>>>>> now
>>>>>>> fixed, however like Willem I think the pre-existing fail-fast
>>>>>>> behaviour
>>>>>>> should be brought back as it used to be there. This however would
>>>>>>> require
>>>>>>> another JIRA-Ticket than [2] having the corresponding description /
>>>>>>> goal.
>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>
>>>>>> However I think we could consider adding a new option to
>>>>>> ResourceEndpoint to support to control if the resource should
>>>>>> be loaded on startup or lazy loaded upon first request. The former has
>>>>>> fail fast, and the latter would defer loading the resource once its
>>>>>> demanded, but with the penalty of compiling/parsing the template
>>>>>> overhead.
>>>>>>
>>>>>> Then the option could be default as the old behavior of loading the
>>>>>> resource on startup.
>>>>>> Wonder what a good name for such an option would be?
>>>>>> - lazyLoadResource
>>>>>> - loadResourceOnStartup
>>>>>> ??
>>>>>>
>>>>>> The mina component have a laztCreateSession option, so the lazy name
>>>>>> could be a good name
>>>>>> http://camel.apache.org/mina
>>>>>>
>>>>>>
>>>>>> Fail fast is IMHO especially needed to allow people to know something
>>>>>> is wrong. We have seen many issues with loading resources in classpath
>>>>>> on various servers of all sorts, and the likes of Java WebStart,
>>>>>> JBoss, OSGi etc.
>>>>>>
>>>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>>> error up front, which can be very important to know.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] https://builds.apache.org/job/******Camel.trunk.fulltest/564/<https://builds.apache.org/job/****Camel.trunk.fulltest/564/>
>>>>>> <**https://builds.apache.org/job/****Camel.trunk.fulltest/564/<https://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>>>> >
>>>>>> <ht**tps://builds.apache.org/**job/**Camel.trunk.fulltest/**564/<http://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>>>> <https://builds.apache.**org/job/Camel.trunk.fulltest/**564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>>>>> >
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> [2] https://issues.apache.org/******jira/browse/CAMEL-4700<https://issues.apache.org/****jira/browse/CAMEL-4700>
>>>>>>> <https:/**/issues.apache.org/**jira/**browse/CAMEL-4700<https://issues.apache.org/**jira/browse/CAMEL-4700>
>>>>>>> >
>>>>>>> <https:/**/issues.apache.org/**jira/**browse/CAMEL-4700<http://issues.apache.org/jira/**browse/CAMEL-4700>
>>>>>>> <https**://issues.apache.org/jira/**browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>>>>> >
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Babak
>>>>>>
>>>>>>
>>>>>>> --
>>>>>>> View this message in context: http://camel.465427.n5.nabble.******
>>>>>>> com/Unit-test-failure-on-******trunk-in-camel-saxon-****
>>>>>>> tp5009713p5012820.html<http://****camel.465427.n5.nabble.com/****<http://camel.465427.n5.nabble.com/**>
>>>>>>> Unit-test-failure-on-trunk-in-****camel-saxon-**
>>>>>>> tp5009713p5012820.**html<http:**//camel.465427.n5.nabble.com/**
>>>>>>> Unit-test-failure-on-trunk-in-**camel-saxon-tp5009713p5012820.**html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Hadrian Zbarcea
>>>>> Principal Software Architect
>>>>> Talend, Inc
>>>>> http://coders.talend.com/
>>>>> http://camelbot.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>> Hadrian Zbarcea
>>> Principal Software Architect
>>> Talend, Inc
>>> http://coders.talend.com/
>>> http://camelbot.blogspot.com/
>>>
>>>
>>
>>
>>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Unit test failure on trunk in camel-saxon
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Good, so I assume we agree that:
Pros:
1. It gives confidence that when a message comes with no header defined
there will be a xslt stylesheet to use, i.e. there is high confidence in
the endpoint configuration.
Cons:
1. This doesn't say much about the quality of the stylesheet, i.e. the
results of xslt processing are the ones expected.
2. Forces you to have the xslt stylesheet provisioned on startup, way
before the first message.
I assume the majority of use cases use one stylesheet configured in the
uri, so the inconsistency is not that relevant.
To be clear, my problem is not with implementing this behavior, but with
introducing new options to support this behavior. Camel is unnecessarily
too complicated as it is. If you think that can be done without
introducing new options, go for it.
I hope this clarifies it,
Hadrian
On 11/22/2011 09:53 AM, Jon Anstey wrote:
> Replace "valid" with "file exists and can be compiled without error";
> essentially putting back in the old startup behavior while keeping the new
> behavior of checking for an XSLT via header on each exchange.
>
> On Tue, Nov 22, 2011 at 11:20 AM, Hadrian Zbarcea<hz...@gmail.com>wrote:
>
>> No. Define valid. Read my previous post.
>> Hadrian
>>
>>
>> On 11/22/2011 09:27 AM, Jon Anstey wrote:
>>
>>> Hey guys,
>>>
>>> Just seeing this thread now (was off for a few days...), of course I only
>>> ran the camel-core tests before committing ;) I'm going to change the
>>> behavior to fail fast again such that if you want to provide XSLT via
>>> header, you will need to also specify a valid XSLT on the URI. So, it will
>>> be useful for the case where you want to override the XSLT on the URI with
>>> one provided via header. Everyone OK with that?
>>>
>>> Cheers,
>>> Jon
>>>
>>> On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea<hz...@gmail.com>**
>>> wrote:
>>>
>>> -1. Why?
>>>>
>>>> Camel got extremely complicated already with a lot of useless features
>>>> and
>>>> options. The way it is now is consistent with the Camel principles:
>>>> * use what's in the header
>>>> * if not, use the endpoint configuration provided via uri
>>>> * if that is not present used hardcoded configuration values.
>>>>
>>>>
>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>> error up front, which can be very important to know.
>>>>>
>>>> It is important to know, that's for sure. Reason why users should test
>>>> their stylesheets before putting them in production. In addition to that,
>>>> the fact that a style compiles doesn't mean that it will behave as
>>>> expected
>>>> when processing a message. Thats guaranteed (as much as possible) by
>>>> knowing your messages and doing thorough testing before going in
>>>> production, not by loading the stylesheet at endpoint creation.
>>>>
>>>> Failing fast is a good principle, we should always try for that, but this
>>>> is not what this proposal is achieving.
>>>>
>>>> My $0.02,
>>>> Hadrian
>>>>
>>>>
>>>>
>>>>
>>>> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>>>>
>>>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<babak.vahdat@**swisson**
>>>>> line.ch<ht...@swissonline.ch>
>>>>>>>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hi
>>>>>>
>>>>>> looking at the build of this morning [1] the test failure issue is now
>>>>>> fixed, however like Willem I think the pre-existing fail-fast behaviour
>>>>>> should be brought back as it used to be there. This however would
>>>>>> require
>>>>>> another JIRA-Ticket than [2] having the corresponding description /
>>>>>> goal.
>>>>>>
>>>>>>
>>>>> +1
>>>>>
>>>>> However I think we could consider adding a new option to
>>>>> ResourceEndpoint to support to control if the resource should
>>>>> be loaded on startup or lazy loaded upon first request. The former has
>>>>> fail fast, and the latter would defer loading the resource once its
>>>>> demanded, but with the penalty of compiling/parsing the template
>>>>> overhead.
>>>>>
>>>>> Then the option could be default as the old behavior of loading the
>>>>> resource on startup.
>>>>> Wonder what a good name for such an option would be?
>>>>> - lazyLoadResource
>>>>> - loadResourceOnStartup
>>>>> ??
>>>>>
>>>>> The mina component have a laztCreateSession option, so the lazy name
>>>>> could be a good name
>>>>> http://camel.apache.org/mina
>>>>>
>>>>>
>>>>> Fail fast is IMHO especially needed to allow people to know something
>>>>> is wrong. We have seen many issues with loading resources in classpath
>>>>> on various servers of all sorts, and the likes of Java WebStart,
>>>>> JBoss, OSGi etc.
>>>>>
>>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>>> error up front, which can be very important to know.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1] https://builds.apache.org/job/****Camel.trunk.fulltest/564/<https://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>>> <ht**tps://builds.apache.org/job/**Camel.trunk.fulltest/564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>>>>>
>>>>>
>>>>>> [2] https://issues.apache.org/****jira/browse/CAMEL-4700<https://issues.apache.org/**jira/browse/CAMEL-4700>
>>>>>> <https:/**/issues.apache.org/jira/**browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Babak
>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://camel.465427.n5.nabble.****
>>>>>> com/Unit-test-failure-on-****trunk-in-camel-saxon-****
>>>>>> tp5009713p5012820.html<http://**camel.465427.n5.nabble.com/**
>>>>>> Unit-test-failure-on-trunk-in-**camel-saxon-tp5009713p5012820.**html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>>>>>>
>>>>>>
>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>> Hadrian Zbarcea
>>>> Principal Software Architect
>>>> Talend, Inc
>>>> http://coders.talend.com/
>>>> http://camelbot.blogspot.com/
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
>>
>
>
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: Unit test failure on trunk in camel-saxon
Posted by Jon Anstey <ja...@gmail.com>.
Replace "valid" with "file exists and can be compiled without error";
essentially putting back in the old startup behavior while keeping the new
behavior of checking for an XSLT via header on each exchange.
On Tue, Nov 22, 2011 at 11:20 AM, Hadrian Zbarcea <hz...@gmail.com>wrote:
> No. Define valid. Read my previous post.
> Hadrian
>
>
> On 11/22/2011 09:27 AM, Jon Anstey wrote:
>
>> Hey guys,
>>
>> Just seeing this thread now (was off for a few days...), of course I only
>> ran the camel-core tests before committing ;) I'm going to change the
>> behavior to fail fast again such that if you want to provide XSLT via
>> header, you will need to also specify a valid XSLT on the URI. So, it will
>> be useful for the case where you want to override the XSLT on the URI with
>> one provided via header. Everyone OK with that?
>>
>> Cheers,
>> Jon
>>
>> On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea<hz...@gmail.com>**
>> wrote:
>>
>> -1. Why?
>>>
>>> Camel got extremely complicated already with a lot of useless features
>>> and
>>> options. The way it is now is consistent with the Camel principles:
>>> * use what's in the header
>>> * if not, use the endpoint configuration provided via uri
>>> * if that is not present used hardcoded configuration values.
>>>
>>>
>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>> error up front, which can be very important to know.
>>>>
>>> It is important to know, that's for sure. Reason why users should test
>>> their stylesheets before putting them in production. In addition to that,
>>> the fact that a style compiles doesn't mean that it will behave as
>>> expected
>>> when processing a message. Thats guaranteed (as much as possible) by
>>> knowing your messages and doing thorough testing before going in
>>> production, not by loading the stylesheet at endpoint creation.
>>>
>>> Failing fast is a good principle, we should always try for that, but this
>>> is not what this proposal is achieving.
>>>
>>> My $0.02,
>>> Hadrian
>>>
>>>
>>>
>>>
>>> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>>>
>>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<babak.vahdat@**swisson**
>>>> line.ch <ht...@swissonline.ch>
>>>> >>
>>>>
>>>> wrote:
>>>>
>>>> Hi
>>>>>
>>>>> looking at the build of this morning [1] the test failure issue is now
>>>>> fixed, however like Willem I think the pre-existing fail-fast behaviour
>>>>> should be brought back as it used to be there. This however would
>>>>> require
>>>>> another JIRA-Ticket than [2] having the corresponding description /
>>>>> goal.
>>>>>
>>>>>
>>>> +1
>>>>
>>>> However I think we could consider adding a new option to
>>>> ResourceEndpoint to support to control if the resource should
>>>> be loaded on startup or lazy loaded upon first request. The former has
>>>> fail fast, and the latter would defer loading the resource once its
>>>> demanded, but with the penalty of compiling/parsing the template
>>>> overhead.
>>>>
>>>> Then the option could be default as the old behavior of loading the
>>>> resource on startup.
>>>> Wonder what a good name for such an option would be?
>>>> - lazyLoadResource
>>>> - loadResourceOnStartup
>>>> ??
>>>>
>>>> The mina component have a laztCreateSession option, so the lazy name
>>>> could be a good name
>>>> http://camel.apache.org/mina
>>>>
>>>>
>>>> Fail fast is IMHO especially needed to allow people to know something
>>>> is wrong. We have seen many issues with loading resources in classpath
>>>> on various servers of all sorts, and the likes of Java WebStart,
>>>> JBoss, OSGi etc.
>>>>
>>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>>> error up front, which can be very important to know.
>>>>
>>>>
>>>>
>>>>
>>>> [1] https://builds.apache.org/job/****Camel.trunk.fulltest/564/<https://builds.apache.org/job/**Camel.trunk.fulltest/564/>
>>>> <ht**tps://builds.apache.org/job/**Camel.trunk.fulltest/564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>>> >
>>>>
>>>>> [2] https://issues.apache.org/****jira/browse/CAMEL-4700<https://issues.apache.org/**jira/browse/CAMEL-4700>
>>>>> <https:/**/issues.apache.org/jira/**browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>> Babak
>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://camel.465427.n5.nabble.****
>>>>> com/Unit-test-failure-on-****trunk-in-camel-saxon-****
>>>>> tp5009713p5012820.html<http://**camel.465427.n5.nabble.com/**
>>>>> Unit-test-failure-on-trunk-in-**camel-saxon-tp5009713p5012820.**html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>>>> >
>>>>>
>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>> Hadrian Zbarcea
>>> Principal Software Architect
>>> Talend, Inc
>>> http://coders.talend.com/
>>> http://camelbot.blogspot.com/
>>>
>>>
>>
>>
>>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Unit test failure on trunk in camel-saxon
Posted by Hadrian Zbarcea <hz...@gmail.com>.
No. Define valid. Read my previous post.
Hadrian
On 11/22/2011 09:27 AM, Jon Anstey wrote:
> Hey guys,
>
> Just seeing this thread now (was off for a few days...), of course I only
> ran the camel-core tests before committing ;) I'm going to change the
> behavior to fail fast again such that if you want to provide XSLT via
> header, you will need to also specify a valid XSLT on the URI. So, it will
> be useful for the case where you want to override the XSLT on the URI with
> one provided via header. Everyone OK with that?
>
> Cheers,
> Jon
>
> On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea<hz...@gmail.com>wrote:
>
>> -1. Why?
>>
>> Camel got extremely complicated already with a lot of useless features and
>> options. The way it is now is consistent with the Camel principles:
>> * use what's in the header
>> * if not, use the endpoint configuration provided via uri
>> * if that is not present used hardcoded configuration values.
>>
>>
>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>> error up front, which can be very important to know.
>> It is important to know, that's for sure. Reason why users should test
>> their stylesheets before putting them in production. In addition to that,
>> the fact that a style compiles doesn't mean that it will behave as expected
>> when processing a message. Thats guaranteed (as much as possible) by
>> knowing your messages and doing thorough testing before going in
>> production, not by loading the stylesheet at endpoint creation.
>>
>> Failing fast is a good principle, we should always try for that, but this
>> is not what this proposal is achieving.
>>
>> My $0.02,
>> Hadrian
>>
>>
>>
>>
>> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>>
>>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<ba...@swissonline.ch>>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> looking at the build of this morning [1] the test failure issue is now
>>>> fixed, however like Willem I think the pre-existing fail-fast behaviour
>>>> should be brought back as it used to be there. This however would require
>>>> another JIRA-Ticket than [2] having the corresponding description / goal.
>>>>
>>>
>>> +1
>>>
>>> However I think we could consider adding a new option to
>>> ResourceEndpoint to support to control if the resource should
>>> be loaded on startup or lazy loaded upon first request. The former has
>>> fail fast, and the latter would defer loading the resource once its
>>> demanded, but with the penalty of compiling/parsing the template
>>> overhead.
>>>
>>> Then the option could be default as the old behavior of loading the
>>> resource on startup.
>>> Wonder what a good name for such an option would be?
>>> - lazyLoadResource
>>> - loadResourceOnStartup
>>> ??
>>>
>>> The mina component have a laztCreateSession option, so the lazy name
>>> could be a good name
>>> http://camel.apache.org/mina
>>>
>>>
>>> Fail fast is IMHO especially needed to allow people to know something
>>> is wrong. We have seen many issues with loading resources in classpath
>>> on various servers of all sorts, and the likes of Java WebStart,
>>> JBoss, OSGi etc.
>>>
>>> Also if there is a issue compiling/parsing the stylesheet you get this
>>> error up front, which can be very important to know.
>>>
>>>
>>>
>>>
>>> [1] https://builds.apache.org/job/**Camel.trunk.fulltest/564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>>> [2] https://issues.apache.org/**jira/browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>>
>>>>
>>>
>>> Babak
>>>>
>>>> --
>>>> View this message in context: http://camel.465427.n5.nabble.**
>>>> com/Unit-test-failure-on-**trunk-in-camel-saxon-**tp5009713p5012820.html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Hadrian Zbarcea
>> Principal Software Architect
>> Talend, Inc
>> http://coders.talend.com/
>> http://camelbot.blogspot.com/
>>
>
>
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: Unit test failure on trunk in camel-saxon
Posted by Jon Anstey <ja...@gmail.com>.
Hey guys,
Just seeing this thread now (was off for a few days...), of course I only
ran the camel-core tests before committing ;) I'm going to change the
behavior to fail fast again such that if you want to provide XSLT via
header, you will need to also specify a valid XSLT on the URI. So, it will
be useful for the case where you want to override the XSLT on the URI with
one provided via header. Everyone OK with that?
Cheers,
Jon
On Tue, Nov 22, 2011 at 10:28 AM, Hadrian Zbarcea <hz...@gmail.com>wrote:
> -1. Why?
>
> Camel got extremely complicated already with a lot of useless features and
> options. The way it is now is consistent with the Camel principles:
> * use what's in the header
> * if not, use the endpoint configuration provided via uri
> * if that is not present used hardcoded configuration values.
>
>
> > Also if there is a issue compiling/parsing the stylesheet you get this
> > error up front, which can be very important to know.
> It is important to know, that's for sure. Reason why users should test
> their stylesheets before putting them in production. In addition to that,
> the fact that a style compiles doesn't mean that it will behave as expected
> when processing a message. Thats guaranteed (as much as possible) by
> knowing your messages and doing thorough testing before going in
> production, not by loading the stylesheet at endpoint creation.
>
> Failing fast is a good principle, we should always try for that, but this
> is not what this proposal is achieving.
>
> My $0.02,
> Hadrian
>
>
>
>
> On 11/22/2011 03:18 AM, Claus Ibsen wrote:
>
>> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<ba...@swissonline.ch>>
>> wrote:
>>
>>> Hi
>>>
>>> looking at the build of this morning [1] the test failure issue is now
>>> fixed, however like Willem I think the pre-existing fail-fast behaviour
>>> should be brought back as it used to be there. This however would require
>>> another JIRA-Ticket than [2] having the corresponding description / goal.
>>>
>>
>> +1
>>
>> However I think we could consider adding a new option to
>> ResourceEndpoint to support to control if the resource should
>> be loaded on startup or lazy loaded upon first request. The former has
>> fail fast, and the latter would defer loading the resource once its
>> demanded, but with the penalty of compiling/parsing the template
>> overhead.
>>
>> Then the option could be default as the old behavior of loading the
>> resource on startup.
>> Wonder what a good name for such an option would be?
>> - lazyLoadResource
>> - loadResourceOnStartup
>> ??
>>
>> The mina component have a laztCreateSession option, so the lazy name
>> could be a good name
>> http://camel.apache.org/mina
>>
>>
>> Fail fast is IMHO especially needed to allow people to know something
>> is wrong. We have seen many issues with loading resources in classpath
>> on various servers of all sorts, and the likes of Java WebStart,
>> JBoss, OSGi etc.
>>
>> Also if there is a issue compiling/parsing the stylesheet you get this
>> error up front, which can be very important to know.
>>
>>
>>
>>
>> [1] https://builds.apache.org/job/**Camel.trunk.fulltest/564/<https://builds.apache.org/job/Camel.trunk.fulltest/564/>
>>> [2] https://issues.apache.org/**jira/browse/CAMEL-4700<https://issues.apache.org/jira/browse/CAMEL-4700>
>>>
>>>
>>
>> Babak
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.**
>>> com/Unit-test-failure-on-**trunk-in-camel-saxon-**tp5009713p5012820.html<http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html>
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
> --
> Hadrian Zbarcea
> Principal Software Architect
> Talend, Inc
> http://coders.talend.com/
> http://camelbot.blogspot.com/
>
--
Cheers,
Jon
---------------
FuseSource
Email: jon@fusesource.com
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Re: Unit test failure on trunk in camel-saxon
Posted by Hadrian Zbarcea <hz...@gmail.com>.
-1. Why?
Camel got extremely complicated already with a lot of useless features
and options. The way it is now is consistent with the Camel principles:
* use what's in the header
* if not, use the endpoint configuration provided via uri
* if that is not present used hardcoded configuration values.
> Also if there is a issue compiling/parsing the stylesheet you get this
> error up front, which can be very important to know.
It is important to know, that's for sure. Reason why users should test
their stylesheets before putting them in production. In addition to
that, the fact that a style compiles doesn't mean that it will behave as
expected when processing a message. Thats guaranteed (as much as
possible) by knowing your messages and doing thorough testing before
going in production, not by loading the stylesheet at endpoint creation.
Failing fast is a good principle, we should always try for that, but
this is not what this proposal is achieving.
My $0.02,
Hadrian
On 11/22/2011 03:18 AM, Claus Ibsen wrote:
> On Tue, Nov 22, 2011 at 9:04 AM, bvahdat<ba...@swissonline.ch> wrote:
>> Hi
>>
>> looking at the build of this morning [1] the test failure issue is now
>> fixed, however like Willem I think the pre-existing fail-fast behaviour
>> should be brought back as it used to be there. This however would require
>> another JIRA-Ticket than [2] having the corresponding description / goal.
>
> +1
>
> However I think we could consider adding a new option to
> ResourceEndpoint to support to control if the resource should
> be loaded on startup or lazy loaded upon first request. The former has
> fail fast, and the latter would defer loading the resource once its
> demanded, but with the penalty of compiling/parsing the template
> overhead.
>
> Then the option could be default as the old behavior of loading the
> resource on startup.
> Wonder what a good name for such an option would be?
> - lazyLoadResource
> - loadResourceOnStartup
> ??
>
> The mina component have a laztCreateSession option, so the lazy name
> could be a good name
> http://camel.apache.org/mina
>
>
> Fail fast is IMHO especially needed to allow people to know something
> is wrong. We have seen many issues with loading resources in classpath
> on various servers of all sorts, and the likes of Java WebStart,
> JBoss, OSGi etc.
>
> Also if there is a issue compiling/parsing the stylesheet you get this
> error up front, which can be very important to know.
>
>
>
>
>> [1] https://builds.apache.org/job/Camel.trunk.fulltest/564/
>> [2] https://issues.apache.org/jira/browse/CAMEL-4700
>>
>
>
>> Babak
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>
>
>
--
Hadrian Zbarcea
Principal Software Architect
Talend, Inc
http://coders.talend.com/
http://camelbot.blogspot.com/
Re: Unit test failure on trunk in camel-saxon
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Nov 22, 2011 at 9:04 AM, bvahdat <ba...@swissonline.ch> wrote:
> Hi
>
> looking at the build of this morning [1] the test failure issue is now
> fixed, however like Willem I think the pre-existing fail-fast behaviour
> should be brought back as it used to be there. This however would require
> another JIRA-Ticket than [2] having the corresponding description / goal.
+1
However I think we could consider adding a new option to
ResourceEndpoint to support to control if the resource should
be loaded on startup or lazy loaded upon first request. The former has
fail fast, and the latter would defer loading the resource once its
demanded, but with the penalty of compiling/parsing the template
overhead.
Then the option could be default as the old behavior of loading the
resource on startup.
Wonder what a good name for such an option would be?
- lazyLoadResource
- loadResourceOnStartup
??
The mina component have a laztCreateSession option, so the lazy name
could be a good name
http://camel.apache.org/mina
Fail fast is IMHO especially needed to allow people to know something
is wrong. We have seen many issues with loading resources in classpath
on various servers of all sorts, and the likes of Java WebStart,
JBoss, OSGi etc.
Also if there is a issue compiling/parsing the stylesheet you get this
error up front, which can be very important to know.
> [1] https://builds.apache.org/job/Camel.trunk.fulltest/564/
> [2] https://issues.apache.org/jira/browse/CAMEL-4700
>
> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Unit test failure on trunk in camel-saxon
Posted by bvahdat <ba...@swissonline.ch>.
Hi
looking at the build of this morning [1] the test failure issue is now
fixed, however like Willem I think the pre-existing fail-fast behaviour
should be brought back as it used to be there. This however would require
another JIRA-Ticket than [2] having the corresponding description / goal.
[1] https://builds.apache.org/job/Camel.trunk.fulltest/564/
[2] https://issues.apache.org/jira/browse/CAMEL-4700
Babak
--
View this message in context: http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5012820.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: Unit test failure on trunk in camel-saxon
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Nov 21, 2011 at 3:23 PM, Willem Jiang <wi...@gmail.com> wrote:
> Current camel-xslt endpoint will not try to load the xslt file until the
> endpoint is processing the first exchange.
> I think we need to let the camel-xslt endpoint load the xslt file when it is
> created to let the user know what is wrong about the endpoint configuration.
> It could save lots of trouble shooting time if we know some thing is wrong
> when the route is started.
>
> Any thoughts ?
Yeah we should fail fast if endpoint configuration is wrong, or
resources cannot be loaded etc.
And in this case a stylesheet cannot be found, and/or not compiled etc.
> On Mon Nov 21 15:45:33 2011, Claus Ibsen wrote:
>>
>> Hi
>>
>> We have a failure on trunk in 1 unit test in camel-saxon
>> Failed tests:
>>
>> testInvalidStylesheet(org.apache.camel.component.xslt.SaxonInvalidXsltFileTest):
>> Should have thrown an exception due XSL compilation error
>>
>> https://builds.apache.org/job/Camel.trunk.fulltest/org.apache.camel$camel-saxon/559/testReport/
>>
>> It's due some recent improvement to load the stylesheet from a header.
>>
>> If anyone got cycles to look into this today or tomorrow that would be
>> great.
>>
>>
>>
>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang Weibo: willemjiang
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Unit test failure on trunk in camel-saxon
Posted by Willem Jiang <wi...@gmail.com>.
Current camel-xslt endpoint will not try to load the xslt file until
the endpoint is processing the first exchange.
I think we need to let the camel-xslt endpoint load the xslt file when
it is created to let the user know what is wrong about the endpoint
configuration.
It could save lots of trouble shooting time if we know some thing is
wrong when the route is started.
Any thoughts ?
On Mon Nov 21 15:45:33 2011, Claus Ibsen wrote:
> Hi
>
> We have a failure on trunk in 1 unit test in camel-saxon
> Failed tests:
> testInvalidStylesheet(org.apache.camel.component.xslt.SaxonInvalidXsltFileTest):
> Should have thrown an exception due XSL compilation error
> https://builds.apache.org/job/Camel.trunk.fulltest/org.apache.camel$camel-saxon/559/testReport/
>
> It's due some recent improvement to load the stylesheet from a header.
>
> If anyone got cycles to look into this today or tomorrow that would be great.
>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang