camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Anstey <jans...@gmail.com>
Subject Re: Unit test failure on trunk in camel-saxon
Date Tue, 22 Nov 2011 14:27:46 GMT
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 <hzbarcea@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@**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/>
>>> [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

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