Great! now the referee on the Wiki [1] is also up-to-date as well.
[1] https://cwiki.apache.org/confluence/display/CAMEL/Building (@ the line
"You can also find some helpful notes on usage here." )
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-tru
Oh wow, that is an old blog post :) I've updated it to point to the new
URLs. Thanks for letting me know!
Cheers,
Jon
On Tue, Nov 22, 2011 at 12:08 PM, bvahdat wrote:
> Hi Jon,
>
> Thanks a lot for your commitment on this and bringing that behaviour back
> into the play.
>
> Other than this I've
Hi Jon,
Thanks a lot for your commitment on this and bringing that behaviour back
into the play.
Other than this I've got another concern which I would really appreciate if
you could take a look at:
As you can see in [1] the links on your old blog entry seem to point to
out-dated eclipse templat
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 ass
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 wrote:
> Good, so I assume we agree that:
>
> Pros:
> 1. It gives confidence that when a message comes wit
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
res
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 previ
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
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
-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 valu
On Tue, Nov 22, 2011 at 9:04 AM, bvahdat 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-Ticke
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]
On Mon, Nov 21, 2011 at 3:23 PM, Willem Jiang wrote:
> Current camel-xslt endpoint will not try to load the xslt file until the
> endpoint is processing the first exchange.
> I think we need to let the camel-xslt endpoint load the xslt file when it is
> created to let the user know what is wrong a
So that by [1] I simply mimicked the same changes done on unit-tests by [2]
[1] https://issues.apache.org/jira/browse/CAMEL-4700
[2] https://issues.apache.org/jira/browse/CAMEL-4689
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-sax
Hi Willem,
completely agree on your proposal, and looking at the changes on the
existing unit-tests by [1], that's [2] & [3] that "fail-fast" behaviour
seems to be gone away.
[1] http://svn.apache.org/viewvc?rev=1202819&view=rev
[2]
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/jav
Hi,
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-tp5009713p5010536.html
Sent from the Camel Development mailing list archive at Nabble.com.
Current camel-xslt endpoint will not try to load the xslt file until
the endpoint is processing the first exchange.
I think we need to let the camel-xslt endpoint load the xslt file when
it is created to let the user know what is wrong about the endpoint
configuration.
It could save lots of trou
17 matches
Mail list logo
