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 <hzbar...@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<hzbar...@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<hzbar...@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.vah...@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: j...@fusesource.com Web: fusesource.com Twitter: jon_anstey Blog: http://janstey.blogspot.com Author of Camel in Action: http://manning.com/ibsen
