Re: [VOTE] Release Apache Camel 2.16.3
+1 Tested against some personal POCs here https://github.com/arnaud-deprez/camel-examples in branch camel-2.16.3 On Tue, Apr 5, 2016 at 7:54 AM Claus Ibsen wrote: > +1 > > On Sun, Apr 3, 2016 at 9:27 PM, Gregor Zurowski > wrote: > > Hi Everyone: > > > > This is a vote to release Apache Camel 2.16.3, a new patch release > > that includes 75+ fixes and improvements. > > > > Release notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334721&projectId=12311211 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachecamel-1049/ > > > > Tarballs: > https://repository.apache.org/content/repositories/orgapachecamel-1049/org/apache/camel/apache-camel/2.16.3/ > > > > Tag: > https://git-wip-us.apache.org/repos/asf?p=camel.git;a=tag;h=91a64b31e0a179b1f217487a638c0f22262d094a > > > > Please test this release candidate and cast your vote. > > [ ] +1 Release the binary as Apache Camel 2.16.3 > > [ ] -1 Veto the release (provide specific comments) > > > > The vote is open for at least 72 hours. > > > > Thanks, > > Gregor > > > > -- > Claus Ibsen > - > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Arnaud Deprez
Allow me to edit the documentation
Hi, I've created my account arnaudep...@gmail.com on confluence. Could you please allow me to edit the documentation ? By the way, how do you manage the documentation between confluence and asciidoc ? Do we have to put special comment in commit and follow some guideline in confluence ? Regards -- Arnaud Deprez
[GitHub] camel pull request: CAMEL-6707: add async for servlet
GitHub user arnaud-deprez opened a pull request: https://github.com/apache/camel/pull/949 CAMEL-6707: add async for servlet Add async option in servlet. # Remarks: I have some issues to test servlet with arquillian & jetty 9. Apparently it doesn't take into account the option async-supported in the web.xml (see test). But it works well with tomcat and the jetty component (because here we register the servlet ourself correctly). You can merge this pull request into a Git repository by running: $ git pull https://github.com/arnaud-deprez/camel CAMEL-6707 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/949.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #949 commit d1a466a96e5b09a87ad83002305ea16fc00c0985 Author: Arnaud Deprez Date: 2016-04-13T21:38:00Z CAMEL-6707: add async for servlet --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Asciidoc(tor) documentation
Hi, +1. I've made a pull request for async with servlet (see https://github.com/apache/camel/pull/949) and I don't know how do I have to do to update the documentation as the asciidoc doesn't exist yet. It's not clear to me too. Regards On Thu, Apr 21, 2016 at 7:50 AM Charles Moulliard wrote: > Hi, > > The only info that I have been able to find about the migration process to > AsciiDoc is part of the contributing web page > > "Most of the documentation is stored on the wiki. We are currently moving > the documentation into the code (AsciiDoc). From there it is automatically > converted to the wiki. So before editing the wiki check the code because > otherwise your changes may be lost. This transition is work-in-progress." > > Do we have more info about that (jira tickets, ...) ? Is it described > somewhere how the HTML content is generated ? Do we use asciidoctor to > render the HTML document ? If this is the case, then we should mention a > link to the asciidoctor web page (user manual, writer manual) and also > indicate that we can use the asciidoctor syntax extending what is proposed > by asciidoc > > Regards, > -- > Charles Moulliard > Apache Committer & PMC / Architect @RedHat > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > -- Arnaud Deprez Software Engineer Phone: +32 497 23 30 44 Linked'In: https://www.linkedin.com/in/deprezarnaud Github: https://github.com/arnaud-deprez
[GitHub] camel pull request: CAMEL-6707: add async for servlet
Github user arnaud-deprez closed the pull request at: https://github.com/apache/camel/pull/949 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Test error in camel-http4
Hi, Just tried on master, I don't meet this issue. On Sat, May 7, 2016 at 3:29 PM Claus Ibsen wrote: > Hi > > Do you also get test error if running the tests in camel-http4 component? > > The CI server has not reported an error in this test. > So just wonder if its something on my end. > > Failed tests: > > org.apache.camel.component.http4.HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties(org.apache.camel.component.http4.HttpProxyServerWithSystemPropertiesTest) > Run 1: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > Run 2: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > Run 3: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > > > > > -- > Claus Ibsen > ----- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > -- Arnaud Deprez Software Engineer Phone: +32 497 23 30 44 Linked'In: https://www.linkedin.com/in/deprezarnaud Github: https://github.com/arnaud-deprez
Re: Test error in camel-http4
Yeah I'm on OS-X as well and from time to time, I get some timeout. By the way, when I tried to reproduced your issue I wasn't on master but intellij shows me I was, my bad. Thanks for having fixed the issue. On Sun, May 8, 2016 at 12:17 PM Babak Vahdat wrote: > > > On 08 May 2016, at 11:31, Claus Ibsen wrote: > > > > Hi > > > > Thanks Babak. The test now also passes on my computer. > > > > Do anyone have problems with camel-jgroups sometime fail testing? I > > have not seen this on the CI servers. > > > > I am on OSX. > > > > > > I’m on OS-X as well but running the camel-jgroups tests for 7 rounds did > not throw me any failing test, so no idea what could be wrong there if > any... > > Babak > > > > > On Sat, May 7, 2016 at 10:07 PM, Babak Vahdat > > wrote: > >> > >>> On 07 May 2016, at 15:29, Claus Ibsen wrote: > >>> > >>> Hi > >>> > >>> Do you also get test error if running the tests in camel-http4 > component? > >>> > >> > >> Used to fail on my end as well which is fixed now. > >> > >> Babak > >> > >>> The CI server has not reported an error in this test. > >>> So just wonder if its something on my end. > >>> > >>> Failed tests: > >>> > org.apache.camel.component.http4.HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties(org.apache.camel.component.http4.HttpProxyServerWithSystemPropertiesTest) > >>> Run 1: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > >>> Run 2: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > >>> Run 3: > HttpProxyServerWithSystemPropertiesTest.httpGetWithProxyFromSystemProperties:108->BaseHttpTest.assertExchange:34->Assert.assertTrue:52->Assert.assertTrue:41->Assert.fail:86 > >>> > >>> > >>> > >>> > >>> -- > >>> Claus Ibsen > >>> - > >>> http://davsclaus.com @davsclaus > >>> Camel in Action 2: https://www.manning.com/ibsen2 > >> > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > -- Arnaud Deprez Software Engineer Phone: +32 497 23 30 44 Linked'In: https://www.linkedin.com/in/deprezarnaud Github: https://github.com/arnaud-deprez
Restriction in RestConfiguration with blueprint
Hi riders,
In camel 2.16.X, I was able to use configure a RestConfiguration in
blueprint with property placeholder as bellow:
http://camel.apache.org/schema/blueprint";>
But since camel 2.16.3 and also in camel 2.17.X and 2.18-SNAPSHOT, it
doesn't work anymore, it is actually unable to resolve the property
placeholder and says that ie. camel can't found a RestConsumerFactory
{{camel.rest.component}}
in the registry.
I think it's related to the fix bring with issue:
https://issues.apache.org/jira/browse/CAMEL-9483
So, according to me, here:
https://github.com/apache/camel/commit/b1555bae4a878135a8681d9bbe895f1f97c96870
at line 996, I think, we should have something like:
String component = CamelContextHelper.parseText(camelContext,
ccfb.getRestConfiguration().getComponent());
instead of
String component = ccfb.getRestConfiguration().getComponent();
Apparently, I can't create a jira issue (can't actually select the Camel
project).
I didn't have time to test it yet, but I'll try to do it soon when I have.
I might also be wrong so please don't hesitate to correct me if I am or
give me some advice if needed.
Regards
--
Arnaud Deprez
Software Engineer
Phone: +32 497 23 30 44
Linked'In: https://www.linkedin.com/in/deprezarnaud
Github: https://github.com/arnaud-deprez
Re: Restriction in RestConfiguration with blueprint
Yeah, I agree Claus.
That's why I'm not a big fan of my proposed solution, It would be cleaner
if the CamelContext (or CamelContextFactoryBean) itself resolved
PropertyPlaceHolder on its own without regarding the implementation
(spring, blueprint, cdi, whatever).
Regards,
On Fri, May 13, 2016 at 7:42 AM Claus Ibsen wrote:
> Hi
>
> Yeah we should avoid setting up those dependencies from the parser if
> they values are using property placeholders
> https://issues.apache.org/jira/browse/CAMEL-9963
>
> On Wed, May 11, 2016 at 11:48 PM, Arnaud Deprez
> wrote:
> > Hi riders,
> >
> > In camel 2.16.X, I was able to use configure a RestConfiguration in
> > blueprint with property placeholder as bellow:
> >
> > http://camel.apache.org/schema/blueprint";>
> > > port="{{camel.rest.port}}" contextPath="{{camel.rest.contextPath}}"/>
> >
> >
> >
> > But since camel 2.16.3 and also in camel 2.17.X and 2.18-SNAPSHOT, it
> > doesn't work anymore, it is actually unable to resolve the property
> > placeholder and says that ie. camel can't found a RestConsumerFactory
> > {{camel.rest.component}}
> > in the registry.
> >
> > I think it's related to the fix bring with issue:
> > https://issues.apache.org/jira/browse/CAMEL-9483
> >
> > So, according to me, here:
> >
> https://github.com/apache/camel/commit/b1555bae4a878135a8681d9bbe895f1f97c96870
> > at line 996, I think, we should have something like:
> > String component = CamelContextHelper.parseText(camelContext,
> > ccfb.getRestConfiguration().getComponent());
> > instead of
> > String component = ccfb.getRestConfiguration().getComponent();
> >
> > Apparently, I can't create a jira issue (can't actually select the Camel
> > project).
> > I didn't have time to test it yet, but I'll try to do it soon when I
> have.
> >
> > I might also be wrong so please don't hesitate to correct me if I am or
> > give me some advice if needed.
> >
> > Regards
> > --
> > Arnaud Deprez
> > Software Engineer
> > Phone: +32 497 23 30 44
> > Linked'In: https://www.linkedin.com/in/deprezarnaud
> > Github: https://github.com/arnaud-deprez
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Arnaud Deprez
Software Engineer
Phone: +32 497 23 30 44
Linked'In: https://www.linkedin.com/in/deprezarnaud
Github: https://github.com/arnaud-deprez
Re: Clustered routes in master/slave mode
+1, I've had this idea too but not the time to get in deeper :-) On Mon, Jun 6, 2016 at 3:51 PM Bilgin Ibryam wrote: > > > > To aid both we should also look at introducing some health API in > > camel-core, so that makes this easier as well. So you can check for > > health status on context / routes level. And custom components can > > implement custom logic to check their health, such as connecting to a > > FTP server and do a FTP list, or do a HTTP remote call etc. > > +1 > You are reading my mind. > > Also, not sure if there is anything we can do to make startup/shutdown > faster. I know there area already lazy converter loader. > > > > > > > > >> -Matt > >> > >> > >> > >> On 5/28/16 2:52 AM, Claus Ibsen wrote: > >>> > >>> Hi > >>> > >>> We have a few components that offer capability to run a Camel routes > >>> in master/slave mode, where one node is elected as master and only > >>> runs the route at that node, and the other nodes are in slave mode, > >>> and then will failover if needed. > >>> > >>> For example camel-zookeeper, and camel-quartz can do that. And now > >>> also camel-consul. And possible others I have forgot. > >>> > >>> I wonder if we should introduce some API those components > >>> implementations can implement so we would better be able to manage and > >>> know about this. Then we can have JMX information about routes being > >>> in master/slave mode, and you can see for example in a 4 node cluster > >>> that its node-b that is the master. > >>> > >>> node-a route-foo: slave > >>> node-b route-foo: master > >>> node-c route-foo: slave > >>> node-d route-foo: slave > >>> > >>> We have a bit old JIRA ticket about this: > >>> https://issues.apache.org/jira/browse/CAMEL-4454 > >>> > >>> > >>> > >>> > >> > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > -- > Bilgin Ibryam > Camel Committer at ASF & Integration Architect at Red Hat > Blog: http://ofbizian.com | Twitter: @bibryam > > Camel Design Patterns https://leanpub.com/camel-design-patterns > Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475 > -- Arnaud Deprez Software Engineer Phone: +32 497 23 30 44 Linked'In: https://www.linkedin.com/in/deprezarnaud Github: https://github.com/arnaud-deprez
Re: Infinite recursion of exceptions. Is it a bug?
Hi Christian,
I think it's expected as you use a global onException handler.
So to not have the recursion problem, you should do something like:
from("direct:test")
.onException(Throwable.class)
.to("direct:handle_er")
.end()
.throwException(new RuntimeException())
.to("log:test2");
from("direct:handle_er")
.throwException(new RuntimeException());
On Thu, May 4, 2017 at 5:30 PM Christian Schneider
wrote:
> I have the routes below. When I send a message to direct:test I get an
> infinite recursion of exceptions.
> The reason is that the onException handler also seems to be called for
> the direct:handle_er that is called when handling the
> first exception. In case such a handler route also throws an exception
> the recursion happens.
>
> Is this expected or a bug?
> If it is not a bug what do we recommend our users to avoid the recursion?
>
> onException(Throwable.class)
> .to("direct:handle_er");
>
> from("direct:test")
> .throwException(new RuntimeException())
> .to("log:test2");
>
> from("direct:handle_er")
> .throwException(new RuntimeException());
>
> See also https://issues.apache.org/jira/browse/CAMEL-11229
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
> --
Arnaud Deprez
Software Engineer
Phone: +32 497 23 30 44
Linked'In: https://www.linkedin.com/in/deprezarnaud
Github: https://github.com/arnaud-deprez
