Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E441C9027 for ; Tue, 22 Nov 2011 15:20:02 +0000 (UTC) Received: (qmail 52792 invoked by uid 500); 22 Nov 2011 15:20:02 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 52722 invoked by uid 500); 22 Nov 2011 15:20:02 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 52714 invoked by uid 99); 22 Nov 2011 15:20:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2011 15:20:02 +0000 X-ASF-Spam-Status: No, hits=0.6 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates 209.85.213.173 as permitted sender) Received: from [209.85.213.173] (HELO mail-yx0-f173.google.com) (209.85.213.173) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2011 15:19:58 +0000 Received: by yenq2 with SMTP id q2so365428yen.32 for ; Tue, 22 Nov 2011 07:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rlnRpt/aX3MkZZWT3KIXutMt7ZFs2IDZrFB3o0CL0+I=; b=UQ7Xy6QpFP2zJzMcllLnwwdGQDdGUTKyWqhGugi7JMyHkLf0t6xCjzQ7sfPlc+0YTp aWAAdcC2GBvTEA+WRNfQDMFaQN65atQXjb9VL0GkP4lPFn7A1IjA+XjEXcrRP6uRYGED uNtY4hMiGMsT7pkYK3kuFSbhnL6QyuNfoCPG4= Received: by 10.236.114.195 with SMTP id c43mr28486436yhh.12.1321975177250; Tue, 22 Nov 2011 07:19:37 -0800 (PST) Received: from [10.40.58.205] (cpe-174-109-047-166.nc.res.rr.com. [174.109.47.166]) by mx.google.com with ESMTPS id m29sm19939010yhi.20.2011.11.22.07.19.35 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:19:35 -0800 (PST) Message-ID: <4ECBBD87.8020302@gmail.com> Date: Tue, 22 Nov 2011 10:19:35 -0500 From: Hadrian Zbarcea User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: dev@camel.apache.org Subject: Re: Unit test failure on trunk in camel-saxon References: <4ECA5EC9.7080301@gmail.com> <1321949054642-5012820.post@n5.nabble.com> <4ECBAA70.2010903@gmail.com> <4ECBB6A0.20703@gmail.com> <4ECBBB85.3080105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Zbarceawrote: > >> 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** >>> 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** >>>>> 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>>>>> >>>>>>> line.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 >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Babak >>>>>>> >>>>>>> >>>>>>>> -- >>>>>>>> View this message in context: http://camel.465427.n5.nabble.****** >>>>>>>> com/Unit-test-failure-on-******trunk-in-camel-saxon-**** >>>>>>>> tp5009713p5012820.html >>>>>>>> Unit-test-failure-on-trunk-in-****camel-saxon-** >>>>>>>> tp5009713p5012820.**html>>>>>>> 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/