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