camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Unit test failure on trunk in camel-saxon
Date Tue, 22 Nov 2011 15:19:35 GMT
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<hzbarcea@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<hzbarcea@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<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@****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/

Mime
View raw message