[jira] [Commented] (CAMEL-13466) DefaultCamelContext not stopping all routes on doStop()
[
https://issues.apache.org/jira/browse/CAMEL-13466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862763#comment-16862763
]
Claus Ibsen commented on CAMEL-13466:
-
That test with throwing an exception in the route builder is wrong, you need to
do this from a route consumer in its doStart etc. I can help with this later.
I think the current PR needs to be polished and the commented out code removed,
also a better code comment why we do this, and we need 2x PRs one for camel-2.x
branch and another for master.
> DefaultCamelContext not stopping all routes on doStop()
> ---
>
> Key: CAMEL-13466
> URL: https://issues.apache.org/jira/browse/CAMEL-13466
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Julien Greffe
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 3.0.0, 2.23.3, 2.24.1, 2.25.0
>
> Attachments: sample-dozer-route-2.0.0-SNAPSHOT.jar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello,
> after applying CAMEL-12980,
> we're still facing an issue with a failing starting feature and the
> CXFServlet {{/services}} URL.
>
> To reproduce :
> * drop the attached JAR in deploy
> * wait for bundle start and failure
> * access {{/services}} URL : endpoint + WSDL are listed > is this an
> expected behaviour?
>
> For further analysis, it seems to be something missing in camel-core :
> When blueprint fails, the {{doStop()}} method is called :
>
> [https://github.com/apache/camel/blob/camel-2.20.1/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L3506]
> At that line, it tries to stop only the routes already started, but not the
> ones failing *before* filling {{routeStartupOrder}} List.
>
> [https://github.com/apache/camel/blob/camel-2.20.1/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L4041]
> One of this routes is a CxfConsumer which has already been instanciated, with
> a server creation :
>
> [https://github.com/apache/camel/blob/camel-2.20.1/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConsumer.java#L69]
> Even with {{DefaultCamelContext.doStop()}}, the server is still started and
> available in {{/services}}.
> Tried a fix by adding this line in DefaultCamelContext:3502 :
> {code:java}
> // fill all the routes to be stopped
> getRouteStartupOrder().addAll(routeServices.values().stream().map(this::doPrepareRouteToBeStarted).collect(Collectors.toList()));
> // stop route inputs in the same order as they was started so we stop the
> very first inputs first
> try {
> // force shutting down routes as they may otherwise cause shutdown to hang
> ...
> {code}
> And now the endpoint isn't available anymore.
> But this fix isn't effective enough as {{getRouteStartupOrder()}} may have
> duplicates?
> Thanks,
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13466) DefaultCamelContext not stopping all routes on doStop()
[
https://issues.apache.org/jira/browse/CAMEL-13466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862761#comment-16862761
]
Claus Ibsen commented on CAMEL-13466:
-
Okay the CxfConsumer is wrong, it should never do such logic in its
constructor, such init logic should be in doInit / doStart etc. So that should
be fixed too.
> DefaultCamelContext not stopping all routes on doStop()
> ---
>
> Key: CAMEL-13466
> URL: https://issues.apache.org/jira/browse/CAMEL-13466
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.1
>Reporter: Julien Greffe
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 3.0.0, 2.23.3, 2.24.1, 2.25.0
>
> Attachments: sample-dozer-route-2.0.0-SNAPSHOT.jar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello,
> after applying CAMEL-12980,
> we're still facing an issue with a failing starting feature and the
> CXFServlet {{/services}} URL.
>
> To reproduce :
> * drop the attached JAR in deploy
> * wait for bundle start and failure
> * access {{/services}} URL : endpoint + WSDL are listed > is this an
> expected behaviour?
>
> For further analysis, it seems to be something missing in camel-core :
> When blueprint fails, the {{doStop()}} method is called :
>
> [https://github.com/apache/camel/blob/camel-2.20.1/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L3506]
> At that line, it tries to stop only the routes already started, but not the
> ones failing *before* filling {{routeStartupOrder}} List.
>
> [https://github.com/apache/camel/blob/camel-2.20.1/camel-core/src/main/java/org/apache/camel/impl/DefaultCamelContext.java#L4041]
> One of this routes is a CxfConsumer which has already been instanciated, with
> a server creation :
>
> [https://github.com/apache/camel/blob/camel-2.20.1/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/CxfConsumer.java#L69]
> Even with {{DefaultCamelContext.doStop()}}, the server is still started and
> available in {{/services}}.
> Tried a fix by adding this line in DefaultCamelContext:3502 :
> {code:java}
> // fill all the routes to be stopped
> getRouteStartupOrder().addAll(routeServices.values().stream().map(this::doPrepareRouteToBeStarted).collect(Collectors.toList()));
> // stop route inputs in the same order as they was started so we stop the
> very first inputs first
> try {
> // force shutting down routes as they may otherwise cause shutdown to hang
> ...
> {code}
> And now the endpoint isn't available anymore.
> But this fix isn't effective enough as {{getRouteStartupOrder()}} may have
> duplicates?
> Thanks,
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13638) camel-salesforce - Lookups to polymorphic relationship fields must include an attributes object with a type property
[
https://issues.apache.org/jira/browse/CAMEL-13638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-13638:
Summary: camel-salesforce - Lookups to polymorphic relationship fields must
include an attributes object with a type property (was: Lookups to polymorphic
relationship fields must include an attributes object with a type property)
> camel-salesforce - Lookups to polymorphic relationship fields must include an
> attributes object with a type property
>
>
> Key: CAMEL-13638
> URL: https://issues.apache.org/jira/browse/CAMEL-13638
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.24.0, 3.0.0-M2
>Reporter: Jeremy Ross
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When referencing a related record that is a polymorphic lookup, the JSON must
> include an {{attributes}} object with a {{type}} property indicating which
> type of Object is being referenced.
> E.g.:
> {code:json}
> {
> "Description": "Contact HR for further information",
> "Status": "Completed",
> "Who": {
> "attributes": {
> "type": "Contact"
> },
> "External_Id_Field__c": "cfcec54d-5d77-4ffa-a2ec-7fa2ce0e9616"
> },
> "Subject": "Comment"
> }
> {code}
> This {{attributes}} object is optional for non-polymorphic lookups, so no
> harm in including it in all lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13638) camel-salesforce - Lookups to polymorphic relationship fields must include an attributes object with a type property
[
https://issues.apache.org/jira/browse/CAMEL-13638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-13638:
Issue Type: Improvement (was: Bug)
> camel-salesforce - Lookups to polymorphic relationship fields must include an
> attributes object with a type property
>
>
> Key: CAMEL-13638
> URL: https://issues.apache.org/jira/browse/CAMEL-13638
> Project: Camel
> Issue Type: Improvement
> Components: camel-salesforce
>Affects Versions: 2.24.0, 3.0.0-M2
>Reporter: Jeremy Ross
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When referencing a related record that is a polymorphic lookup, the JSON must
> include an {{attributes}} object with a {{type}} property indicating which
> type of Object is being referenced.
> E.g.:
> {code:json}
> {
> "Description": "Contact HR for further information",
> "Status": "Completed",
> "Who": {
> "attributes": {
> "type": "Contact"
> },
> "External_Id_Field__c": "cfcec54d-5d77-4ffa-a2ec-7fa2ce0e9616"
> },
> "Subject": "Comment"
> }
> {code}
> This {{attributes}} object is optional for non-polymorphic lookups, so no
> harm in including it in all lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13641) Jenkins Job for website deployment doesn't have timeout config
[ https://issues.apache.org/jira/browse/CAMEL-13641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-13641: - Priority: Minor (was: Major) > Jenkins Job for website deployment doesn't have timeout config > -- > > Key: CAMEL-13641 > URL: https://issues.apache.org/jira/browse/CAMEL-13641 > Project: Camel > Issue Type: Wish >Reporter: Huang Yunkun >Assignee: Andrea Cosentino >Priority: Minor > > hey team, > Could you please take a look at this jenkins job: > [https://builds.apache.org/job/Camel.website/job/pr%252Fcaching/1/] > Somehow it takes more than one day and still running. There is only one > jenkins slave with access to do website build and gitbox push, so there are > many job pending now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13641) Jenkins Job for website deployment doesn't have timeout config
[ https://issues.apache.org/jira/browse/CAMEL-13641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-13641. -- Resolution: Fixed > Jenkins Job for website deployment doesn't have timeout config > -- > > Key: CAMEL-13641 > URL: https://issues.apache.org/jira/browse/CAMEL-13641 > Project: Camel > Issue Type: Wish >Reporter: Huang Yunkun >Assignee: Andrea Cosentino >Priority: Minor > > hey team, > Could you please take a look at this jenkins job: > [https://builds.apache.org/job/Camel.website/job/pr%252Fcaching/1/] > Somehow it takes more than one day and still running. There is only one > jenkins slave with access to do website build and gitbox push, so there are > many job pending now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-13641) Jenkins Job for website deployment doesn't have timeout config
[ https://issues.apache.org/jira/browse/CAMEL-13641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-13641: Assignee: Andrea Cosentino > Jenkins Job for website deployment doesn't have timeout config > -- > > Key: CAMEL-13641 > URL: https://issues.apache.org/jira/browse/CAMEL-13641 > Project: Camel > Issue Type: Wish >Reporter: Huang Yunkun >Assignee: Andrea Cosentino >Priority: Major > > hey team, > Could you please take a look at this jenkins job: > [https://builds.apache.org/job/Camel.website/job/pr%252Fcaching/1/] > Somehow it takes more than one day and still running. There is only one > jenkins slave with access to do website build and gitbox push, so there are > many job pending now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13641) Jenkins Job for website deployment doesn't have timeout config
[ https://issues.apache.org/jira/browse/CAMEL-13641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862744#comment-16862744 ] Andrea Cosentino commented on CAMEL-13641: -- I stopped the job. Seems to be a temporary glitch. > Jenkins Job for website deployment doesn't have timeout config > -- > > Key: CAMEL-13641 > URL: https://issues.apache.org/jira/browse/CAMEL-13641 > Project: Camel > Issue Type: Wish >Reporter: Huang Yunkun >Priority: Major > > hey team, > Could you please take a look at this jenkins job: > [https://builds.apache.org/job/Camel.website/job/pr%252Fcaching/1/] > Somehow it takes more than one day and still running. There is only one > jenkins slave with access to do website build and gitbox push, so there are > many job pending now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13641) Jenkins Job for website deployment doesn't have timeout config
Huang Yunkun created CAMEL-13641: Summary: Jenkins Job for website deployment doesn't have timeout config Key: CAMEL-13641 URL: https://issues.apache.org/jira/browse/CAMEL-13641 Project: Camel Issue Type: Wish Reporter: Huang Yunkun hey team, Could you please take a look at this jenkins job: [https://builds.apache.org/job/Camel.website/job/pr%252Fcaching/1/] Somehow it takes more than one day and still running. There is only one jenkins slave with access to do website build and gitbox push, so there are many job pending now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13640) Camel Split with Aggregate, calling subroute with onException (handled = true) stops, doesn't work the same way as calling a sub route using doTry
[
https://issues.apache.org/jira/browse/CAMEL-13640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Daswani updated CAMEL-13640:
---
Description:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the camel-users list - [for
example|[http://camel.465427.n5.nabble.com/Split-with-Aggregation-when-throw-Exception-issue-td5750159.html]]
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
was:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the camel-users list.
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
> Camel Split with Aggregate, calling subroute with onException (handled =
> true) stops, doesn't work the same way as calling a sub route using doTry
> ---
>
> Key: CAMEL-13640
> URL: https://issues.apache.org/jira/browse/CAMEL-13640
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.24.0
>Reporter: George Daswani
>Priority: Major
> Attachments: BugReport.zip
>
>
> Split with Aggregate calling a sub route that has handled exception (eq.
> direct:exceptionStart) doesn't behave the same as one calling a sub route
> swallowing exceptions using doTry (eq. direct:doTryStart)
> The two should be functionally equivalent but the one calling the sub route
> with onException stops prematurely. It never gets to ".log("done with split
> and aggregate").
> Others have reported the same thing on the camel-users list - [for
> example|[http://camel.465427.n5.nabble.com/Split-with-Aggregation-when-throw-Exception-issue-td5750159.html]]
> Sample program attached (maven project) - BugReport.zip
>
> {code:java}
> public void configure() throws Exception {
> from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnException").end().log("done with split and
> aggregate");
> from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
> .handled(true).end().log("${body}").throwException(new Exception("an
> Error!"));
> from("direct:doTryStart").routeId("doTryStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnDoTry").end().log("done with split and aggregate");
> from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
> .throwException(new Exception("an
> Error!")).endDoTry().doCa
[jira] [Updated] (CAMEL-13640) Camel Split with Aggregate, calling subroute with onException (handled = true) stops, doesn't work the same way as calling a sub route using doTry
[
https://issues.apache.org/jira/browse/CAMEL-13640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Daswani updated CAMEL-13640:
---
Description:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the camel-users list - [for
example|http://camel.465427.n5.nabble.com/Split-with-Aggregation-when-throw-Exception-issue-td5750159.html]
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
was:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the camel-users list - [for
example|[http://camel.465427.n5.nabble.com/Split-with-Aggregation-when-throw-Exception-issue-td5750159.html]]
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
> Camel Split with Aggregate, calling subroute with onException (handled =
> true) stops, doesn't work the same way as calling a sub route using doTry
> ---
>
> Key: CAMEL-13640
> URL: https://issues.apache.org/jira/browse/CAMEL-13640
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.24.0
>Reporter: George Daswani
>Priority: Major
> Attachments: BugReport.zip
>
>
> Split with Aggregate calling a sub route that has handled exception (eq.
> direct:exceptionStart) doesn't behave the same as one calling a sub route
> swallowing exceptions using doTry (eq. direct:doTryStart)
> The two should be functionally equivalent but the one calling the sub route
> with onException stops prematurely. It never gets to ".log("done with split
> and aggregate").
> Others have reported the same thing on the camel-users list - [for
> example|http://camel.465427.n5.nabble.com/Split-with-Aggregation-when-throw-Exception-issue-td5750159.html]
> Sample program attached (maven project) - BugReport.zip
>
> {code:java}
> public void configure() throws Exception {
> from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnException").end().log("done with split and
> aggregate");
> from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
> .handled(true).end().log("${body}").throwException(new Exception("an
> Error!"));
> from("direct:doTryStart").routeId("doTryStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnDoTry").end().log("done with split and aggregate");
> from("direct:processItemOnDoTry").rout
[jira] [Updated] (CAMEL-13640) Camel Split with Aggregate, calling subroute with onException (handled = true) stops, doesn't work the same way as calling a sub route using doTry
[
https://issues.apache.org/jira/browse/CAMEL-13640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Daswani updated CAMEL-13640:
---
Description:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the camel-users list.
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
was:
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the
[forums|http://camel.465427.n5.nabble.com/endDoTry-problem-td5543541.html]
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
> Camel Split with Aggregate, calling subroute with onException (handled =
> true) stops, doesn't work the same way as calling a sub route using doTry
> ---
>
> Key: CAMEL-13640
> URL: https://issues.apache.org/jira/browse/CAMEL-13640
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.24.0
>Reporter: George Daswani
>Priority: Major
> Attachments: BugReport.zip
>
>
> Split with Aggregate calling a sub route that has handled exception (eq.
> direct:exceptionStart) doesn't behave the same as one calling a sub route
> swallowing exceptions using doTry (eq. direct:doTryStart)
> The two should be functionally equivalent but the one calling the sub route
> with onException stops prematurely. It never gets to ".log("done with split
> and aggregate").
> Others have reported the same thing on the camel-users list.
> Sample program attached (maven project) - BugReport.zip
>
> {code:java}
> public void configure() throws Exception {
> from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnException").end().log("done with split and
> aggregate");
> from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
> .handled(true).end().log("${body}").throwException(new Exception("an
> Error!"));
> from("direct:doTryStart").routeId("doTryStart").split(body(), new
> MyAggregationStrategy())
> .to("direct:processItemOnDoTry").end().log("done with split and aggregate");
> from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
> .throwException(new Exception("an
> Error!")).endDoTry().doCatch(Exception.class)
> .log("swallowed exception");
> }{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13640) Camel Split with Aggregate, calling subroute with onException (handled = true) stops, doesn't work the same way as calling a sub route using doTry
George Daswani created CAMEL-13640:
--
Summary: Camel Split with Aggregate, calling subroute with
onException (handled = true) stops, doesn't work the same way as calling a sub
route using doTry
Key: CAMEL-13640
URL: https://issues.apache.org/jira/browse/CAMEL-13640
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.24.0
Reporter: George Daswani
Attachments: BugReport.zip
Split with Aggregate calling a sub route that has handled exception (eq.
direct:exceptionStart) doesn't behave the same as one calling a sub route
swallowing exceptions using doTry (eq. direct:doTryStart)
The two should be functionally equivalent but the one calling the sub route
with onException stops prematurely. It never gets to ".log("done with split
and aggregate").
Others have reported the same thing on the
[forums|http://camel.465427.n5.nabble.com/endDoTry-problem-td5543541.html]
Sample program attached (maven project) - BugReport.zip
{code:java}
public void configure() throws Exception {
from("direct:exceptionStart").routeId("exceptionStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnException").end().log("done with split and aggregate");
from("direct:processItemOnException").routeId("processItemOnException").onException(Exception.class)
.handled(true).end().log("${body}").throwException(new Exception("an Error!"));
from("direct:doTryStart").routeId("doTryStart").split(body(), new
MyAggregationStrategy())
.to("direct:processItemOnDoTry").end().log("done with split and aggregate");
from("direct:processItemOnDoTry").routeId("processItemOnDoTry").doTry().log("${body}")
.throwException(new Exception("an Error!")).endDoTry().doCatch(Exception.class)
.log("swallowed exception");
}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13639) camel-pulsar build is flaky
[ https://issues.apache.org/jira/browse/CAMEL-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862336#comment-16862336 ] Alex Dettinger commented on CAMEL-13639: Starting the container manually demonstrates that the namespace is there. However, it could be that the metric endpoint answers before the actual registration. I will try first to waitFor "/admin/v2/namespaces/public" to answer HTTP 200 as it works locally. > camel-pulsar build is flaky > --- > > Key: CAMEL-13639 > URL: https://issues.apache.org/jira/browse/CAMEL-13639 > Project: Camel > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Alex Dettinger >Priority: Major > > The camel-pulsar build sometime fails with an error message containing > "Policies not found for public/default namespace". > But actually, the default/namespace should be in the container out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-13639) camel-pulsar build is flaky
[ https://issues.apache.org/jira/browse/CAMEL-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger reassigned CAMEL-13639: -- Assignee: Alex Dettinger > camel-pulsar build is flaky > --- > > Key: CAMEL-13639 > URL: https://issues.apache.org/jira/browse/CAMEL-13639 > Project: Camel > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Alex Dettinger >Assignee: Alex Dettinger >Priority: Major > > The camel-pulsar build sometime fails with an error message containing > "Policies not found for public/default namespace". > But actually, the default/namespace should be in the container out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13639) camel-pulsar build is flaky
[ https://issues.apache.org/jira/browse/CAMEL-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger updated CAMEL-13639: --- Affects Version/s: 3.0.0-M3 > camel-pulsar build is flaky > --- > > Key: CAMEL-13639 > URL: https://issues.apache.org/jira/browse/CAMEL-13639 > Project: Camel > Issue Type: Bug >Affects Versions: 3.0.0-M3 >Reporter: Alex Dettinger >Priority: Major > > The camel-pulsar build sometime fails with an error message containing > "Policies not found for public/default namespace". > But actually, the default/namespace should be in the container out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13639) camel-pulsar build is flaky
[ https://issues.apache.org/jira/browse/CAMEL-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger updated CAMEL-13639: --- Issue Type: Bug (was: Task) > camel-pulsar build is flaky > --- > > Key: CAMEL-13639 > URL: https://issues.apache.org/jira/browse/CAMEL-13639 > Project: Camel > Issue Type: Bug >Reporter: Alex Dettinger >Priority: Major > > The camel-pulsar build sometime fails with an error message containing > "Policies not found for public/default namespace". > But actually, the default/namespace should be in the container out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13639) camel-pulsar build is flaky
Alex Dettinger created CAMEL-13639: -- Summary: camel-pulsar build is flaky Key: CAMEL-13639 URL: https://issues.apache.org/jira/browse/CAMEL-13639 Project: Camel Issue Type: Task Reporter: Alex Dettinger The camel-pulsar build sometime fails with an error message containing "Policies not found for public/default namespace". But actually, the default/namespace should be in the container out of the box. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (CAMEL-13638) Lookups to polymorphic relationship fields must include an attributes object with a type property
[
https://issues.apache.org/jira/browse/CAMEL-13638?focusedWorklogId=258794&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-258794
]
ASF GitHub Bot logged work on CAMEL-13638:
--
Author: ASF GitHub Bot
Created on: 12/Jun/19 14:56
Start Date: 12/Jun/19 14:56
Worklog Time Spent: 10m
Work Description: jeremyross commented on pull request #2974:
CAMEL-13638: Include attributes/type info in relationship lookups.
URL: https://github.com/apache/camel/pull/2974
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 258794)
Time Spent: 10m
Remaining Estimate: 0h
> Lookups to polymorphic relationship fields must include an attributes object
> with a type property
> -
>
> Key: CAMEL-13638
> URL: https://issues.apache.org/jira/browse/CAMEL-13638
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
>Affects Versions: 2.24.0, 3.0.0-M2
>Reporter: Jeremy Ross
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When referencing a related record that is a polymorphic lookup, the JSON must
> include an {{attributes}} object with a {{type}} property indicating which
> type of Object is being referenced.
> E.g.:
> {code:json}
> {
> "Description": "Contact HR for further information",
> "Status": "Completed",
> "Who": {
> "attributes": {
> "type": "Contact"
> },
> "External_Id_Field__c": "cfcec54d-5d77-4ffa-a2ec-7fa2ce0e9616"
> },
> "Subject": "Comment"
> }
> {code}
> This {{attributes}} object is optional for non-polymorphic lookups, so no
> harm in including it in all lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13638) Lookups to polymorphic relationship fields must include an attributes object with a type property
Jeremy Ross created CAMEL-13638:
---
Summary: Lookups to polymorphic relationship fields must include
an attributes object with a type property
Key: CAMEL-13638
URL: https://issues.apache.org/jira/browse/CAMEL-13638
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 3.0.0-M2, 2.24.0
Reporter: Jeremy Ross
When referencing a related record that is a polymorphic lookup, the JSON must
include an {{attributes}} object with a {{type}} property indicating which type
of Object is being referenced.
E.g.:
{code:json}
{
"Description": "Contact HR for further information",
"Status": "Completed",
"Who": {
"attributes": {
"type": "Contact"
},
"External_Id_Field__c": "cfcec54d-5d77-4ffa-a2ec-7fa2ce0e9616"
},
"Subject": "Comment"
}
{code}
This {{attributes}} object is optional for non-polymorphic lookups, so no harm
in including it in all lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13637) be able to enable access log for camel-undertow consumer endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862170#comment-16862170 ] Jan Bednar commented on CAMEL-13637: It would be awesome, if AccessLogReceiver could be pluggable bean in registry, so the access log entry can be postprocessed (and maybe redirected to another route and postprocessed eg with camel-grok). > be able to enable access log for camel-undertow consumer endpoint > - > > Key: CAMEL-13637 > URL: https://issues.apache.org/jira/browse/CAMEL-13637 > Project: Camel > Issue Type: Improvement > Components: camel-undertow >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.0.0 > > > add a option/flag so we can configure camel-undertow consumer endpoint to > enable access log per each request -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13633) AuthenticationFailedException is not propagated to onException route
[
https://issues.apache.org/jira/browse/CAMEL-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862140#comment-16862140
]
Andrea Cosentino commented on CAMEL-13633:
--
[https://github.com/apache/camel/blob/master/components/camel-mail/src/main/docs/mail-component.adoc]
The official documentation is this one and it's documented.
> AuthenticationFailedException is not propagated to onException route
>
>
> Key: CAMEL-13633
> URL: https://issues.apache.org/jira/browse/CAMEL-13633
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.24.0
>Reporter: Kamil
>Priority: Major
>
> If imaps Compotent throws:
>
> {code:java}
> javax.mail.AuthenticationFailedException: [AUTHENTICATIONFAILED] Invalid
> credentials (Failure)
> at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:732)
> at javax.mail.Service.connect(Service.java:388)
> at
> org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:521)
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:95)
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> It is not propagated to onException Route.
> Test case:
> {code:java}
> import javax.mail.AuthenticationFailedException;
> import org.apache.camel.EndpointInject;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Produce;
> import org.apache.camel.ProducerTemplate;
> import org.apache.camel.RoutesBuilder;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.mock.MockEndpoint;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.apache.http.client.utils.URIBuilder;
> import org.junit.Test;
> public class EmailRouteTest extends CamelTestSupport {
> private static final String STATIC_ROUTE_FROM = "direct:email";
> @EndpointInject(uri = "mock:error")
> private MockEndpoint mockErrorEndpoint;
> @Produce(uri = STATIC_ROUTE_FROM)
> private ProducerTemplate sender;
> @Override
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> final String routeUri = new URIBuilder()
> .setScheme("imaps")
> .setHost("imap.gmail.com")
> .setPort(993)
> .addParameter("username", "foobar")
> .addParameter("password", "foobar")
> .addParameter("debugMode", "false")
> .addParameter("delete", "false")
> .addParameter("unseen", "true")
> .addParameter("consumer.delay", "6")
> .toString();
> onException(Exception.class)
> .handled(true)
> .to(mockErrorEndpoint);
> from(routeUri)
> .to("stream:out");
> }
> };
> }
> @Test
> public void shouldInterceptError() throws Exception {
> mockErrorEndpoint.expectedMessageCount(1);
> mockErrorEndpoint.expectedMessagesMatches(ex ->
> ex.getProperty(Exchange.EXCEPTION_CAUGHT).getClass().equals(AuthenticationFailedException.class));
> mockErrorEndpoint.assertIsSatisfied();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13633) AuthenticationFailedException is not propagated to onException route
[
https://issues.apache.org/jira/browse/CAMEL-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862141#comment-16862141
]
Jan Bednar commented on CAMEL-13633:
This is there for reason. In the most cases you dont want to get filled your
onException route with exception for every poll (eg two exceptions per second
for file endpoint, one per minute for mail endpoint). In most cases you want to
handle this in separate logic. If you really need to handle this in onException
block, then every endpoint have option `consumer.bridgeErrorHandler=true` which
does exactly this.
> AuthenticationFailedException is not propagated to onException route
>
>
> Key: CAMEL-13633
> URL: https://issues.apache.org/jira/browse/CAMEL-13633
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.24.0
>Reporter: Kamil
>Priority: Major
>
> If imaps Compotent throws:
>
> {code:java}
> javax.mail.AuthenticationFailedException: [AUTHENTICATIONFAILED] Invalid
> credentials (Failure)
> at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:732)
> at javax.mail.Service.connect(Service.java:388)
> at
> org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:521)
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:95)
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> It is not propagated to onException Route.
> Test case:
> {code:java}
> import javax.mail.AuthenticationFailedException;
> import org.apache.camel.EndpointInject;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Produce;
> import org.apache.camel.ProducerTemplate;
> import org.apache.camel.RoutesBuilder;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.mock.MockEndpoint;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.apache.http.client.utils.URIBuilder;
> import org.junit.Test;
> public class EmailRouteTest extends CamelTestSupport {
> private static final String STATIC_ROUTE_FROM = "direct:email";
> @EndpointInject(uri = "mock:error")
> private MockEndpoint mockErrorEndpoint;
> @Produce(uri = STATIC_ROUTE_FROM)
> private ProducerTemplate sender;
> @Override
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> final String routeUri = new URIBuilder()
> .setScheme("imaps")
> .setHost("imap.gmail.com")
> .setPort(993)
> .addParameter("username", "foobar")
> .addParameter("password", "foobar")
> .addParameter("debugMode", "false")
> .addParameter("delete", "false")
> .addParameter("unseen", "true")
> .addParameter("consumer.delay", "6")
> .toString();
> onException(Exception.class)
> .handled(true)
> .to(mockErrorEndpoint);
> from(routeUri)
> .to("stream:out");
> }
> };
> }
> @Test
> public void shouldInterceptError() throws Exception {
> mockErrorEndpoint.expectedMessageCount(1);
> mockErrorEndpoint.expectedMessagesMatches(ex ->
> ex.getProperty(Exchange.EXCEPTION_CAUGHT).getClass().equals(AuthenticationFailedException.class));
> mockErrorEndpoint.assertIsSatisfied();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13637) be able to enable access log for camel-undertow consumer endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862136#comment-16862136 ] Freeman Fang commented on CAMEL-13637: -- an access log entry for one request looks like "2019-06-12 10:07:54,919 [XNIO-18 task-1 ] INFO accesslog - 127.0.0.1 - - [12/Jun/2019:10:07:54 -0400] "POST /foo HTTP/1.1" 200 4" > be able to enable access log for camel-undertow consumer endpoint > - > > Key: CAMEL-13637 > URL: https://issues.apache.org/jira/browse/CAMEL-13637 > Project: Camel > Issue Type: Improvement > Components: camel-undertow >Reporter: Freeman Fang >Assignee: Freeman Fang >Priority: Major > Fix For: 3.0.0 > > > add a option/flag so we can configure camel-undertow consumer endpoint to > enable access log per each request -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13633) AuthenticationFailedException is not propagated to onException route
[
https://issues.apache.org/jira/browse/CAMEL-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862129#comment-16862129
]
Kamil commented on CAMEL-13633:
---
Or maybe bridgeErrorHandler (which is not even documented as option here:
[https://camel.apache.org/mail.html]) could be default true?
> AuthenticationFailedException is not propagated to onException route
>
>
> Key: CAMEL-13633
> URL: https://issues.apache.org/jira/browse/CAMEL-13633
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.24.0
>Reporter: Kamil
>Priority: Major
>
> If imaps Compotent throws:
>
> {code:java}
> javax.mail.AuthenticationFailedException: [AUTHENTICATIONFAILED] Invalid
> credentials (Failure)
> at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:732)
> at javax.mail.Service.connect(Service.java:388)
> at
> org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:521)
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:95)
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> It is not propagated to onException Route.
> Test case:
> {code:java}
> import javax.mail.AuthenticationFailedException;
> import org.apache.camel.EndpointInject;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Produce;
> import org.apache.camel.ProducerTemplate;
> import org.apache.camel.RoutesBuilder;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.mock.MockEndpoint;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.apache.http.client.utils.URIBuilder;
> import org.junit.Test;
> public class EmailRouteTest extends CamelTestSupport {
> private static final String STATIC_ROUTE_FROM = "direct:email";
> @EndpointInject(uri = "mock:error")
> private MockEndpoint mockErrorEndpoint;
> @Produce(uri = STATIC_ROUTE_FROM)
> private ProducerTemplate sender;
> @Override
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> final String routeUri = new URIBuilder()
> .setScheme("imaps")
> .setHost("imap.gmail.com")
> .setPort(993)
> .addParameter("username", "foobar")
> .addParameter("password", "foobar")
> .addParameter("debugMode", "false")
> .addParameter("delete", "false")
> .addParameter("unseen", "true")
> .addParameter("consumer.delay", "6")
> .toString();
> onException(Exception.class)
> .handled(true)
> .to(mockErrorEndpoint);
> from(routeUri)
> .to("stream:out");
> }
> };
> }
> @Test
> public void shouldInterceptError() throws Exception {
> mockErrorEndpoint.expectedMessageCount(1);
> mockErrorEndpoint.expectedMessagesMatches(ex ->
> ex.getProperty(Exchange.EXCEPTION_CAUGHT).getClass().equals(AuthenticationFailedException.class));
> mockErrorEndpoint.assertIsSatisfied();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13637) be able to enable access log for camel-undertow consumer endpoint
Freeman Fang created CAMEL-13637: Summary: be able to enable access log for camel-undertow consumer endpoint Key: CAMEL-13637 URL: https://issues.apache.org/jira/browse/CAMEL-13637 Project: Camel Issue Type: Improvement Components: camel-undertow Reporter: Freeman Fang Assignee: Freeman Fang Fix For: 3.0.0 add a option/flag so we can configure camel-undertow consumer endpoint to enable access log per each request -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13633) AuthenticationFailedException is not propagated to onException route
[
https://issues.apache.org/jira/browse/CAMEL-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16862124#comment-16862124
]
Kamil commented on CAMEL-13633:
---
1) Even if Camel "works that way" currently, it does not mean it is the best
way possible. It breaks the "principle of least surprise" for sure. I
understand "Chicken or te egg problem" but maybe this issue could be a
improvement request to make it better in Camel 3.0?
2) You say that "This exception occured during consumer initialization", but
what if someone will change password while Camel is running? Message will not
be routed, but this is no longer "initialization" of the Component. Am I right?
> AuthenticationFailedException is not propagated to onException route
>
>
> Key: CAMEL-13633
> URL: https://issues.apache.org/jira/browse/CAMEL-13633
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.24.0
>Reporter: Kamil
>Priority: Major
>
> If imaps Compotent throws:
>
> {code:java}
> javax.mail.AuthenticationFailedException: [AUTHENTICATIONFAILED] Invalid
> credentials (Failure)
> at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:732)
> at javax.mail.Service.connect(Service.java:388)
> at
> org.apache.camel.component.mail.MailConsumer.ensureIsConnected(MailConsumer.java:521)
> at
> org.apache.camel.component.mail.MailConsumer.poll(MailConsumer.java:95)
> at
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> at
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> It is not propagated to onException Route.
> Test case:
> {code:java}
> import javax.mail.AuthenticationFailedException;
> import org.apache.camel.EndpointInject;
> import org.apache.camel.Exchange;
> import org.apache.camel.Processor;
> import org.apache.camel.Produce;
> import org.apache.camel.ProducerTemplate;
> import org.apache.camel.RoutesBuilder;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.component.mock.MockEndpoint;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.apache.http.client.utils.URIBuilder;
> import org.junit.Test;
> public class EmailRouteTest extends CamelTestSupport {
> private static final String STATIC_ROUTE_FROM = "direct:email";
> @EndpointInject(uri = "mock:error")
> private MockEndpoint mockErrorEndpoint;
> @Produce(uri = STATIC_ROUTE_FROM)
> private ProducerTemplate sender;
> @Override
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> final String routeUri = new URIBuilder()
> .setScheme("imaps")
> .setHost("imap.gmail.com")
> .setPort(993)
> .addParameter("username", "foobar")
> .addParameter("password", "foobar")
> .addParameter("debugMode", "false")
> .addParameter("delete", "false")
> .addParameter("unseen", "true")
> .addParameter("consumer.delay", "6")
> .toString();
> onException(Exception.class)
> .handled(true)
> .to(mockErrorEndpoint);
> from(routeUri)
> .to("stream:out");
> }
> };
> }
> @Test
> public void shouldInterceptError() throws Exception {
> mockErrorEndpoint.expectedMessageCount(1);
> mockErrorEndpoint.expectedMessagesMatches(ex ->
> ex.getProperty(Exchange.EXCEPTION_CAUGHT).getClass().equals(AuthenticationFailedException.class));
> mockErrorEndpoint.assertIsSatisfied();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CAMEL-13636) camel3 - SPI for ReactiveHelper so we can plugin different reactive engines
[ https://issues.apache.org/jira/browse/CAMEL-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13636: --- Assignee: Claus Ibsen > camel3 - SPI for ReactiveHelper so we can plugin different reactive engines > --- > > Key: CAMEL-13636 > URL: https://issues.apache.org/jira/browse/CAMEL-13636 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > Today we use ReactiveHelper.callback(callback) to execute works in Camel > routing engine. We should have a SPI so we can plugin 3rd party. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13636) camel3 - SPI for ReactiveHelper so we can plugin different reactive engines
Claus Ibsen created CAMEL-13636: --- Summary: camel3 - SPI for ReactiveHelper so we can plugin different reactive engines Key: CAMEL-13636 URL: https://issues.apache.org/jira/browse/CAMEL-13636 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Fix For: 3.0.0, 3.0.0.M4 Today we use ReactiveHelper.callback(callback) to execute works in Camel routing engine. We should have a SPI so we can plugin 3rd party. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13635) camel3 - Warmup routes and EIPs in init phase
[ https://issues.apache.org/jira/browse/CAMEL-13635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13635: Estimated Complexity: Advanced (was: Unknown) > camel3 - Warmup routes and EIPs in init phase > - > > Key: CAMEL-13635 > URL: https://issues.apache.org/jira/browse/CAMEL-13635 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > We should add a stage for doInit to warmup the Camel routes where we can > prepare all the services with doInit and EIPs can also move some of their > start logic to init, for init once. > Then we can init a CamelContext as part of preparing and warming up at a > build phase, that then leaves the start stage to runtime phase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13635) camel3 - Warmup routes and EIPs in init phase
Claus Ibsen created CAMEL-13635: --- Summary: camel3 - Warmup routes and EIPs in init phase Key: CAMEL-13635 URL: https://issues.apache.org/jira/browse/CAMEL-13635 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Fix For: 3.0.0, 3.0.0.M4 We should add a stage for doInit to warmup the Camel routes where we can prepare all the services with doInit and EIPs can also move some of their start logic to init, for init once. Then we can init a CamelContext as part of preparing and warming up at a build phase, that then leaves the start stage to runtime phase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861976#comment-16861976
]
Christoph Giera commented on CAMEL-13621:
-
You mean using the underlying URISupport.sanitizeUri? We will loose masking for
xml and json values.
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13634) Camel main - Allow to configure rest dsl configuration
[
https://issues.apache.org/jira/browse/CAMEL-13634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861941#comment-16861941
]
Claus Ibsen edited comment on CAMEL-13634 at 6/12/19 9:33 AM:
--
{code}
# to configure Rest DSL (global and you need to add camel-undertow to the
classpath)
camel.rest.component=undertow
camel.rest.port=8080
camel.rest.component-properties[host-options.buffer-size]=8192
code}
was (Author: davsclaus):
# to configure Rest DSL (global and you need to add camel-undertow to the
classpath)
### camel.rest.component=undertow
### camel.rest.port=8080
### camel.rest.component-properties[host-options.buffer-size]=8192
> Camel main - Allow to configure rest dsl configuration
> --
>
> Key: CAMEL-13634
> URL: https://issues.apache.org/jira/browse/CAMEL-13634
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0, 3.0.0.M4
>
>
> So you can configure in application.properties etc, some of the rest dsl
> configuration you would otherwise have to configure with restConfiguration()
> in the java dsl
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13634) Camel main - Allow to configure rest dsl configuration
[ https://issues.apache.org/jira/browse/CAMEL-13634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13634. - Resolution: Fixed # to configure Rest DSL (global and you need to add camel-undertow to the classpath) ### camel.rest.component=undertow ### camel.rest.port=8080 ### camel.rest.component-properties[host-options.buffer-size]=8192 > Camel main - Allow to configure rest dsl configuration > -- > > Key: CAMEL-13634 > URL: https://issues.apache.org/jira/browse/CAMEL-13634 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > So you can configure in application.properties etc, some of the rest dsl > configuration you would otherwise have to configure with restConfiguration() > in the java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13634) Camel main - Allow to configure rest dsl configuration
[
https://issues.apache.org/jira/browse/CAMEL-13634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861941#comment-16861941
]
Claus Ibsen edited comment on CAMEL-13634 at 6/12/19 9:33 AM:
--
{code}
# to configure Rest DSL (global and you need to add camel-undertow to the
classpath)
camel.rest.component=undertow
camel.rest.port=8080
camel.rest.component-properties[host-options.buffer-size]=8192
{code}
was (Author: davsclaus):
{code}
# to configure Rest DSL (global and you need to add camel-undertow to the
classpath)
camel.rest.component=undertow
camel.rest.port=8080
camel.rest.component-properties[host-options.buffer-size]=8192
code}
> Camel main - Allow to configure rest dsl configuration
> --
>
> Key: CAMEL-13634
> URL: https://issues.apache.org/jira/browse/CAMEL-13634
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0, 3.0.0.M4
>
>
> So you can configure in application.properties etc, some of the rest dsl
> configuration you would otherwise have to configure with restConfiguration()
> in the java dsl
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861920#comment-16861920
]
Claus Ibsen commented on CAMEL-13621:
-
Okay if you build the string yourself and you know its an endpoint uri, then
use as DefaultEndpoint toString does for masking.
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861917#comment-16861917
]
Christoph Giera commented on CAMEL-13621:
-
The use-case is pretty simple:
We trace our route executions in a DB table. E.g. if an error occured we store
it in a DB field . It's possible that this information contains sensitive
data(like password in a camel uri). I knew that there exists a solution for
masking in the camel framework because the log component has a masking option
and there I found the DefaultMaskingFormatter. I thought "when the log
component uses this I can also use it :) "
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-11727) Upgrade Groovy to version containing Ivy fixes for cache resolution
[ https://issues.apache.org/jira/browse/CAMEL-11727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-11727: Priority: Minor (was: Major) > Upgrade Groovy to version containing Ivy fixes for cache resolution > --- > > Key: CAMEL-11727 > URL: https://issues.apache.org/jira/browse/CAMEL-11727 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Affects Versions: 2.19.2 >Reporter: Aurélien Pupier >Priority: Minor > > the targeted version is not released yet, the goal is to contain the > following fixes: > - [GROOVY-8305] > - [IVY-1566] via [GROOVY-8304] > there is at least one API break with > org.apache.camel.catalog.maven.TimeoutHttpClientHandler which extends a class > which is no more visible org.apache.ivy.util.url.HttpClientHandler -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-11292) support for Scala 2.12.x
[ https://issues.apache.org/jira/browse/CAMEL-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-11292. - Resolution: Won't Fix Fix Version/s: 3.0.0 camel-scala is deprecated and removed from camel 3 onwards > support for Scala 2.12.x > > > Key: CAMEL-11292 > URL: https://issues.apache.org/jira/browse/CAMEL-11292 > Project: Camel > Issue Type: New Feature > Components: camel-scala >Affects Versions: 2.19.0 >Reporter: Sarunas Valaskevicius >Priority: Minor > Fix For: 3.0.0 > > > currently camel-scala depends on Scala 2.11. could this be upgraded to 2.12.x > release? > Same with scalatest. > All possible updates can be seen here - > https://mvnrepository.com/artifact/org.apache.camel/camel-scala/2.19.0 > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12655) Endpoints: Helper method with setters/getters to easily construct endpoint URIs
[ https://issues.apache.org/jira/browse/CAMEL-12655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12655. - Resolution: Duplicate Fix Version/s: 3.0.0 There is a endpoint fluent dsl in the works > Endpoints: Helper method with setters/getters to easily construct endpoint > URIs > --- > > Key: CAMEL-12655 > URL: https://issues.apache.org/jira/browse/CAMEL-12655 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.21.1 >Reporter: Prakhar >Priority: Minor > Labels: Endpoint, component, uri > Fix For: 3.0.0 > > > Right now all the camel endpoints/URI's are string based. As a developer, I > need to construct them manually and have to be aware of the changes brought > in with each new release. I would be more confident in working with URIs if I > could get some basic type checking as well as some helper methods to quickly > construct the URIs. For example a set of setter methods for the properties > and a single getter method for the endpoint. > I have been constructing my own utility classes, to achieve this. for ex. > have a look at > [apache-camel-kafka|https://github.com/PrakharSrivastav/apache-camel-kafka/blob/master/src/main/java/utils/kafka/KafkaEndpointBuilder.java] > for working with Kafka endpoints. And the way I use this builder is > [usage-of-endpointbuilder > |https://github.com/PrakharSrivastav/apache-camel-kafka/blob/master/src/main/java/routes/bank/BankProcessPayment.java] > It would be really helpful to have this feature shipped with the individual > camel-components. This is a crude example but highlights the use case for the > feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12975) WARN: No CamelContext defined yet so cannot inject into bean: org.apache.camel.converter.jaxb.FallbackTypeConverter
[
https://issues.apache.org/jira/browse/CAMEL-12975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861846#comment-16861846
]
Claus Ibsen commented on CAMEL-12975:
-
Can you try with latest version
> WARN: No CamelContext defined yet so cannot inject into bean:
> org.apache.camel.converter.jaxb.FallbackTypeConverter
> ---
>
> Key: CAMEL-12975
> URL: https://issues.apache.org/jira/browse/CAMEL-12975
> Project: Camel
> Issue Type: Bug
> Components: camel-jaxb, camel-spring-boot-starters
>Affects Versions: 2.23.0
>Reporter: Pascal Schumacher
>Priority: Minor
> Fix For: 3.0.0, 2.24.0
>
>
> I'm using camel-jaxb-starter 2.23.0 in combination with Spring Boot 2.1.1.
> During start-up this warning is displayed:
> {{WARN 15204 --- [ main] o.a.c.i.DefaultCamelBeanPostProcessor:
> No CamelContext defined yet so cannot inject into bean:
> org.apache.camel.converter.jaxb.FallbackTypeConverter}}
> Otherwise everything is working fine (as far as I can tell).
> I created a minimal project that allows reproducing this warning:
> https://github.com/PascalSchumacher/CamelJaxbStartupWarning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13032) camel-core - cs checks fixes
[ https://issues.apache.org/jira/browse/CAMEL-13032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13032. - Resolution: Implemented Fix Version/s: 3.0.0 > camel-core - cs checks fixes > > > Key: CAMEL-13032 > URL: https://issues.apache.org/jira/browse/CAMEL-13032 > Project: Camel > Issue Type: Task >Reporter: Önder Sezgin >Priority: Minor > Fix For: 3.0.0 > > > There is two more. Needs more attention because applying what needs to be > done according to cs check output misleads and causes other problems. > > [INFO] Starting audit... > [ERROR] > C:\gitrepo\camel\camel-core\src\main\java\org\apache\camel\processor\interceptor\BacklogDebugger.java:64: > Class BacklogDebugger should be declared as final. [FinalClass] > [ERROR] > C:\gitrepo\camel\camel-core\src\main\java\org\apache\camel\support\AsyncProcessorConverterHelper.java:50: > Class ProcessorToAsyncProcessorBridge should be declared as final. > [FinalClass] > Audit done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12464) Add support for context in Jolt
[ https://issues.apache.org/jira/browse/CAMEL-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12464. - Resolution: Fixed Has been merged last year > Add support for context in Jolt > --- > > Key: CAMEL-12464 > URL: https://issues.apache.org/jira/browse/CAMEL-12464 > Project: Camel > Issue Type: Improvement > Components: camel-jolt >Affects Versions: 2.21.0 >Reporter: Ganesh Pagade >Priority: Major > Labels: newbie > > Jolt context allows parameterizing the spec file passing dynamic values at > runtime: > [https://github.com/bazaarvoice/jolt/blob/master/jolt-core/src/main/java/com/bazaarvoice/jolt/ContextualTransform.java] > This is a useful feature of Jolt which one should also be able to use using > Apache Camel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-8555) on using Guice modules - give user control on when context starts
[ https://issues.apache.org/jira/browse/CAMEL-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8555. Resolution: Won't Fix Fix Version/s: 3.0.0 camel-guice is deprecated and removed from camel 3 onwards > on using Guice modules - give user control on when context starts > - > > Key: CAMEL-8555 > URL: https://issues.apache.org/jira/browse/CAMEL-8555 > Project: Camel > Issue Type: Improvement > Components: camel-guice >Reporter: moritz löser >Priority: Minor > Fix For: 3.0.0 > > > In my application i need to do some stuff before i want camel to start. in a > normal camel app you would just call main.run(). > The problem on using the camel modules is that they all start the context on > "@PostConstruct" so as soon as the injector is constructed the context starts. > I would suggest a CamelModule or an option (constructor parameter) to disable > this auto start behavior. So with disabled autostart one must call > org.apache.camel.guice.Main.run(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13393) NullPointerException on opentracing example
[
https://issues.apache.org/jira/browse/CAMEL-13393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-13393.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 3.0.0-M3
> NullPointerException on opentracing example
> ---
>
> Key: CAMEL-13393
> URL: https://issues.apache.org/jira/browse/CAMEL-13393
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0-M2
>Reporter: Zoran Regvart
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0-M3
>
>
> When running service1 from of the opentracing example an NullPointerException
> is logged to the standard out:
> {code}
> 2019-04-05 10:33:54.620 INFO 23268 --- [ main]
> o.a.camel.spring.boot.RoutesCollector: Starting CamelMainRunController to
> ensure the main thread keeps running
> [WARNING]
> java.lang.RuntimeException: java.lang.NullPointerException
> at org.apache.camel.spring.boot.CamelSpringBootApplicationController.run
> (CamelSpringBootApplicationController.java:83)
> at org.apache.camel.spring.boot.CamelMainRunController$DaemonTask.run
> (1m2Cam20melM1ainRunController.java:53)9
> -04-05 10:33:54.622 INFO at5m23268 java.lang.Thread.run --- [
> main] o.a.c.impl.DefaultStreamCachingStrategy : StreamCaching in use with
> spool directory: /tmp/camel/camel-tmp-4e01e06f-baf2-4a4c-abce-89e2a14f7516
> and rules: [Sp (Thread.java:748)
> ool > 128K body size]
> Caused by: java.lang.NullPointerException
> at org.apache.camel.main.MainSupport.postProcessCamelContext
> (MainSupport.java:745)
> at org.apache.camel.main.MainSupport.initCamelContext
> (MainSupport.java:676)
> at org.apache.camel.main.Main.doStart (Main.java:107)
> at org.apache.camel.support.service.ServiceSupport.start
> (ServiceSupport.java:86)
> at org.apache.camel.main.MainSupport.run (MainSupport.java:203)
> at org.apache.camel.spring.boot.CamelSpringBootApplicationController.run
> (CamelSpringBootApplicationController.java:78)
> at org.apache.camel.spring.boot.CamelMainRunController$DaemonTask.run
> (CamelMainRunController.java:53)
> at java.lang.Thread.run (Thread.java:748)
> {code}
> Take a look at CAMEL-13386 on how to reproduce.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13634) Camel main - Allow to configure rest dsl configuration
Claus Ibsen created CAMEL-13634: --- Summary: Camel main - Allow to configure rest dsl configuration Key: CAMEL-13634 URL: https://issues.apache.org/jira/browse/CAMEL-13634 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.0.0, 3.0.0.M4 So you can configure in application.properties etc, some of the rest dsl configuration you would otherwise have to configure with restConfiguration() in the java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13354) Camel main - Allow to configure hystrix via application.properties
[ https://issues.apache.org/jira/browse/CAMEL-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-13354. - Resolution: Fixed > Camel main - Allow to configure hystrix via application.properties > -- > > Key: CAMEL-13354 > URL: https://issues.apache.org/jira/browse/CAMEL-13354 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > So you can easily configure hystrix from property placeholders in > application.properties etc, which you can do with spring boot etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13354) Camel main - Allow to configure hystrix via application.properties
[ https://issues.apache.org/jira/browse/CAMEL-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861827#comment-16861827 ] Claus Ibsen commented on CAMEL-13354: - You can now use camel.hystrix.xxx to set the default hystrix config. > Camel main - Allow to configure hystrix via application.properties > -- > > Key: CAMEL-13354 > URL: https://issues.apache.org/jira/browse/CAMEL-13354 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > So you can easily configure hystrix from property placeholders in > application.properties etc, which you can do with spring boot etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-13354) Camel main - Allow to configure hystrix via application.properties
[ https://issues.apache.org/jira/browse/CAMEL-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13354: --- Assignee: Claus Ibsen > Camel main - Allow to configure hystrix via application.properties > -- > > Key: CAMEL-13354 > URL: https://issues.apache.org/jira/browse/CAMEL-13354 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > > So you can easily configure hystrix from property placeholders in > application.properties etc, which you can do with spring boot etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13354) Camel main - Allow to configure hystrix via application.properties
[ https://issues.apache.org/jira/browse/CAMEL-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13354: Fix Version/s: 3.0.0.M4 > Camel main - Allow to configure hystrix via application.properties > -- > > Key: CAMEL-13354 > URL: https://issues.apache.org/jira/browse/CAMEL-13354 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.M4 > > > So you can easily configure hystrix from property placeholders in > application.properties etc, which you can do with spring boot etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
