[jira] [Commented] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096775#comment-16096775
]
ASF GitHub Bot commented on CAMEL-11575:
GitHub user adessaigne opened a pull request:
https://github.com/apache/camel/pull/1841
CAMEL-11575 - Rename http4s into https4 which is the real component name
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adessaigne/camel CAMEL-11575
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1841.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 #1841
commit 62476324ac4a1be12a4a44c7df5cd980dd3e719c
Author: Antoine DESSAIGNE
Date: 2017-07-21T20:04:54Z
CAMEL-11575 - Rename http4s into https4 which is the real component name
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096508#comment-16096508
]
Luca Burgazzoli edited comment on CAMEL-11575 at 7/21/17 5:00 PM:
--
The cloud stuff simple search for :
{code}
${scheme-of-the-component}-service-expression.
{code}
I do not think there is a test for such variations so please raise a jira to
add them.
was (Author: lb):
The cloud stuff simple search for
${scheme-of-the-component}-service-expression, I do not think there is a test
for such variations so please raise a jira to add them.
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096508#comment-16096508
]
Luca Burgazzoli commented on CAMEL-11575:
-
The cloud stuff simple search for
${scheme-of-the-component}-service-expression, I do not think there is a test
for such variations so please raise a jira to add them.
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096467#comment-16096467
]
Antoine DESSAIGNE commented on CAMEL-11575:
---
I'll try to update the new cloud stuff but I don't know how to test it. Do you
have info or docs to give me ? Thanks.
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096451#comment-16096451
]
Claus Ibsen commented on CAMEL-11575:
-
Yes it should be named like the file in the META-INF/services folder. So it
should be named: https4
A PR is much welcome
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11576) camel-catalog is not generating camel-stream URI properly
[
https://issues.apache.org/jira/browse/CAMEL-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096458#comment-16096458
]
ASF GitHub Bot commented on CAMEL-11576:
Github user adessaigne closed the pull request at:
https://github.com/apache/camel/pull/1840
> camel-catalog is not generating camel-stream URI properly
> -
>
> Key: CAMEL-11576
> URL: https://issues.apache.org/jira/browse/CAMEL-11576
> Project: Camel
> Issue Type: Bug
> Components: camel-catalog
>Reporter: Antoine DESSAIGNE
>Assignee: Claus Ibsen
> Fix For: 2.19.2, 2.20.0
>
>
> The endpoint URI generation in {{camel-catalog}} doesn't work for the
> {{camel-stream}} component. Here is an extract of the {{camel-stream.json}}
> file with only relevant information for this bug
> {code}
> {
> "component": {
> "syntax": "stream:kind",
> },
> "properties": {
> "kind": { "kind": "path", "enum": [ "in", "out", "err", "header", "file",
> "url" ] },
> "url": { "kind": "parameter" },
> }
> }
> {code}
> The key point is that one of the value for the {{kind}} property that is in
> the path is {{url}} which is also query parameter.
> For instance the following code
> {code}
> Map map = new LinkedHashMap<>();
> map.put("kind", "url");
> map.put("url", "http://camel.apache.org";);
> String uri = catalog.asEndpointUri("stream", map, false);
> {code}
> will return
> {code}
> stream:http://camel.apache.org
> {code}
> instead of
> {code}
> stream:url?url=http://camel.apache.org
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096455#comment-16096455
]
Claus Ibsen commented on CAMEL-11575:
-
Also there is a name problem in that new cloud stuff (that is not a component)
but we should ideally have it the same name as the component with
https4-service-expression
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11575) Component name mismatch: https4 or http4s
[
https://issues.apache.org/jira/browse/CAMEL-11575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-11575:
Fix Version/s: 2.20.0
2.19.2
> Component name mismatch: https4 or http4s
> -
>
> Key: CAMEL-11575
> URL: https://issues.apache.org/jira/browse/CAMEL-11575
> Project: Camel
> Issue Type: Bug
> Components: camel-http4
>Reporter: Antoine DESSAIGNE
> Fix For: 2.19.2, 2.20.0
>
>
> I noticed a mismatch for the https protocol handling of {{camel-http4}}.
> Sometimes it's named {{https4}} like in:
> * {{org.apache.camel.component.http4.HttpComponent}}
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
> Sometimes it's named {{http4s}} like in:
> *
> {{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
> * {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
> annotatation
> * {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
> I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
> I think that it should be named {{https4}} but I wanted to be sure before
> providing a pull request that update all erroneous call to {{http4s}}.
> What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11576) camel-catalog is not generating camel-stream URI properly
[
https://issues.apache.org/jira/browse/CAMEL-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11576.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.20.0
2.19.2
Thanks for the PR
> camel-catalog is not generating camel-stream URI properly
> -
>
> Key: CAMEL-11576
> URL: https://issues.apache.org/jira/browse/CAMEL-11576
> Project: Camel
> Issue Type: Bug
> Components: camel-catalog
>Reporter: Antoine DESSAIGNE
>Assignee: Claus Ibsen
> Fix For: 2.19.2, 2.20.0
>
>
> The endpoint URI generation in {{camel-catalog}} doesn't work for the
> {{camel-stream}} component. Here is an extract of the {{camel-stream.json}}
> file with only relevant information for this bug
> {code}
> {
> "component": {
> "syntax": "stream:kind",
> },
> "properties": {
> "kind": { "kind": "path", "enum": [ "in", "out", "err", "header", "file",
> "url" ] },
> "url": { "kind": "parameter" },
> }
> }
> {code}
> The key point is that one of the value for the {{kind}} property that is in
> the path is {{url}} which is also query parameter.
> For instance the following code
> {code}
> Map map = new LinkedHashMap<>();
> map.put("kind", "url");
> map.put("url", "http://camel.apache.org";);
> String uri = catalog.asEndpointUri("stream", map, false);
> {code}
> will return
> {code}
> stream:http://camel.apache.org
> {code}
> instead of
> {code}
> stream:url?url=http://camel.apache.org
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11574) camel-lumberjack should support longs
[
https://issues.apache.org/jira/browse/CAMEL-11574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-11574:
Fix Version/s: 2.20.0
> camel-lumberjack should support longs
> -
>
> Key: CAMEL-11574
> URL: https://issues.apache.org/jira/browse/CAMEL-11574
> Project: Camel
> Issue Type: Improvement
>Reporter: Antoine DESSAIGNE
> Fix For: 2.20.0
>
>
> Filebeat 5 introduced json parsing options that allow using resources more
> efficiently but the {{camel-lumberjack}} component unmarshalling behaves
> badly with long values so we can't take advantage of it.
> Right now the following log message :
> {code}
> {"long":1491320561000}
> {code}
> With the following route
> {code:xml}
>
> http://camel.apache.org/schema/spring";
> xmlns:u="http://www.systar.com/aluminium/camel-util";>
>
>
>
>
>
> {code}
> Will produce the following console log
> {noformat}
> just received : long=1.491320561E12 .
> {noformat}
> instead of
> {noformat}
> just received : long=1491320561000 .
> {noformat}
> Even if JSON is _not_ supposed to handle longs, implementations such as
> Jackson do support it which is really handy. So switching from Gson to
> Jackson for JSON handling we'll be usefull.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11572) camel-lumberjack component doesn't restart
[
https://issues.apache.org/jira/browse/CAMEL-11572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11572.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.20.0
2.19.2
2.18.5
> camel-lumberjack component doesn't restart
> --
>
> Key: CAMEL-11572
> URL: https://issues.apache.org/jira/browse/CAMEL-11572
> Project: Camel
> Issue Type: Bug
>Reporter: Antoine DESSAIGNE
>Assignee: Claus Ibsen
> Fix For: 2.18.5, 2.19.2, 2.20.0
>
>
> Hello.
> There's an issue in the {{camel-lumberjack}} component lifecycle preventing
> it from restarting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11572) camel-lumberjack component doesn't restart
[
https://issues.apache.org/jira/browse/CAMEL-11572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096446#comment-16096446
]
ASF GitHub Bot commented on CAMEL-11572:
Github user adessaigne closed the pull request at:
https://github.com/apache/camel/pull/1838
> camel-lumberjack component doesn't restart
> --
>
> Key: CAMEL-11572
> URL: https://issues.apache.org/jira/browse/CAMEL-11572
> Project: Camel
> Issue Type: Bug
>Reporter: Antoine DESSAIGNE
>Assignee: Claus Ibsen
> Fix For: 2.18.5, 2.19.2, 2.20.0
>
>
> Hello.
> There's an issue in the {{camel-lumberjack}} component lifecycle preventing
> it from restarting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11576) camel-catalog is not generating camel-stream URI properly
[
https://issues.apache.org/jira/browse/CAMEL-11576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096337#comment-16096337
]
ASF GitHub Bot commented on CAMEL-11576:
GitHub user adessaigne opened a pull request:
https://github.com/apache/camel/pull/1840
CAMEL-11576 - Refactor endpoint syntax handling in order to support
camel-stream component
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adessaigne/camel CAMEL-11576
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1840.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 #1840
commit 3bc2ef81352a925fdbf38365f6e889cc7deafd14
Author: Antoine DESSAIGNE
Date: 2017-07-21T14:48:30Z
CAMEL-11576 - Refactor endpoint syntax handling in order to support
camel-stream component
> camel-catalog is not generating camel-stream URI properly
> -
>
> Key: CAMEL-11576
> URL: https://issues.apache.org/jira/browse/CAMEL-11576
> Project: Camel
> Issue Type: Bug
> Components: camel-catalog
>Reporter: Antoine DESSAIGNE
>
> The endpoint URI generation in {{camel-catalog}} doesn't work for the
> {{camel-stream}} component. Here is an extract of the {{camel-stream.json}}
> file with only relevant information for this bug
> {code}
> {
> "component": {
> "syntax": "stream:kind",
> },
> "properties": {
> "kind": { "kind": "path", "enum": [ "in", "out", "err", "header", "file",
> "url" ] },
> "url": { "kind": "parameter" },
> }
> }
> {code}
> The key point is that one of the value for the {{kind}} property that is in
> the path is {{url}} which is also query parameter.
> For instance the following code
> {code}
> Map map = new LinkedHashMap<>();
> map.put("kind", "url");
> map.put("url", "http://camel.apache.org";);
> String uri = catalog.asEndpointUri("stream", map, false);
> {code}
> will return
> {code}
> stream:http://camel.apache.org
> {code}
> instead of
> {code}
> stream:url?url=http://camel.apache.org
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11576) camel-catalog is not generating camel-stream URI properly
Antoine DESSAIGNE created CAMEL-11576:
-
Summary: camel-catalog is not generating camel-stream URI properly
Key: CAMEL-11576
URL: https://issues.apache.org/jira/browse/CAMEL-11576
Project: Camel
Issue Type: Bug
Components: camel-catalog
Reporter: Antoine DESSAIGNE
The endpoint URI generation in {{camel-catalog}} doesn't work for the
{{camel-stream}} component. Here is an extract of the {{camel-stream.json}}
file with only relevant information for this bug
{code}
{
"component": {
"syntax": "stream:kind",
},
"properties": {
"kind": { "kind": "path", "enum": [ "in", "out", "err", "header", "file",
"url" ] },
"url": { "kind": "parameter" },
}
}
{code}
The key point is that one of the value for the {{kind}} property that is in the
path is {{url}} which is also query parameter.
For instance the following code
{code}
Map map = new LinkedHashMap<>();
map.put("kind", "url");
map.put("url", "http://camel.apache.org";);
String uri = catalog.asEndpointUri("stream", map, false);
{code}
will return
{code}
stream:http://camel.apache.org
{code}
instead of
{code}
stream:url?url=http://camel.apache.org
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11575) Component name mismatch: https4 or http4s
Antoine DESSAIGNE created CAMEL-11575:
-
Summary: Component name mismatch: https4 or http4s
Key: CAMEL-11575
URL: https://issues.apache.org/jira/browse/CAMEL-11575
Project: Camel
Issue Type: Bug
Components: camel-http4
Reporter: Antoine DESSAIGNE
I noticed a mismatch for the https protocol handling of {{camel-http4}}.
Sometimes it's named {{https4}} like in:
* {{org.apache.camel.component.http4.HttpComponent}}
*
{{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\component\https4}}
Sometimes it's named {{http4s}} like in:
*
{{components\camel-http4\src\main\resources\META-INF\services\org\apache\camel\cloud\http4s-service-expression}}
* {{org.apache.camel.component.http4.HttpEndpoint}} for {{@UriEndpoint}}
annotatation
* {{org.apache.camel.impl.cloud.DefaultServiceCallExpression}}
I noticed that it breaks the {{camel-catalog}} as the definition is incorrect.
I think that it should be named {{https4}} but I wanted to be sure before
providing a pull request that update all erroneous call to {{http4s}}.
What do you think ?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11574) camel-lumberjack should support longs
[
https://issues.apache.org/jira/browse/CAMEL-11574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096224#comment-16096224
]
ASF GitHub Bot commented on CAMEL-11574:
GitHub user adessaigne opened a pull request:
https://github.com/apache/camel/pull/1839
CAMEL-11574 - Switch lumberjack from Gson to Jackson in order to support
long JSon values
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adessaigne/camel CAMEL-11574
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1839.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 #1839
commit 38bd1d3ebc09e78ac7b6d6aa244c7d91e22d94af
Author: Antoine DESSAIGNE
Date: 2017-07-21T13:13:18Z
CAMEL-11574 - Switch lumberjack from Gson to Jackson in order to support
long JSon values
> camel-lumberjack should support longs
> -
>
> Key: CAMEL-11574
> URL: https://issues.apache.org/jira/browse/CAMEL-11574
> Project: Camel
> Issue Type: Improvement
>Reporter: Antoine DESSAIGNE
>
> Filebeat 5 introduced json parsing options that allow using resources more
> efficiently but the {{camel-lumberjack}} component unmarshalling behaves
> badly with long values so we can't take advantage of it.
> Right now the following log message :
> {code}
> {"long":1491320561000}
> {code}
> With the following route
> {code:xml}
>
> http://camel.apache.org/schema/spring";
> xmlns:u="http://www.systar.com/aluminium/camel-util";>
>
>
>
>
>
> {code}
> Will produce the following console log
> {noformat}
> just received : long=1.491320561E12 .
> {noformat}
> instead of
> {noformat}
> just received : long=1491320561000 .
> {noformat}
> Even if JSON is _not_ supposed to handle longs, implementations such as
> Jackson do support it which is really handy. So switching from Gson to
> Jackson for JSON handling we'll be usefull.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11573) Enable MultipleConsumersSupport for Jt400Endpoint
Rafał Gała created CAMEL-11573: -- Summary: Enable MultipleConsumersSupport for Jt400Endpoint Key: CAMEL-11573 URL: https://issues.apache.org/jira/browse/CAMEL-11573 Project: Camel Issue Type: New Feature Components: camel-jt400 Reporter: Rafał Gała Priority: Minor We set up a Camel route that consumes messages from AS400 data queue in 20 concurrent tasks using a secure connection. The problem is that on AS400 system all communication is handled by a single thread and maximum throughput we can achieve is somewhere around 300mbps. It simply reaches a CPU processing limit and just cannot do more bceause all communication is being done within a single connection to AS400 system. If Jt400Endpoint class implemented MultipleConsumersSupport interface, we would be able to set up multiple consumers for this endpoint which would result in more than one connection to AS400 thus the processing would be split to many threads on AS400 system. When we disable security and the traffic is unencrypted, the problem goes away, but we really would like to stick with encrypted traffic. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11574) camel-lumberjack should support longs
Antoine DESSAIGNE created CAMEL-11574:
-
Summary: camel-lumberjack should support longs
Key: CAMEL-11574
URL: https://issues.apache.org/jira/browse/CAMEL-11574
Project: Camel
Issue Type: Improvement
Reporter: Antoine DESSAIGNE
Filebeat 5 introduced json parsing options that allow using resources more
efficiently but the {{camel-lumberjack}} component unmarshalling behaves badly
with long values so we can't take advantage of it.
Right now the following log message :
{code}
{"long":1491320561000}
{code}
With the following route
{code:xml}
http://camel.apache.org/schema/spring";
xmlns:u="http://www.systar.com/aluminium/camel-util";>
{code}
Will produce the following console log
{noformat}
just received : long=1.491320561E12 .
{noformat}
instead of
{noformat}
just received : long=1491320561000 .
{noformat}
Even if JSON is _not_ supposed to handle longs, implementations such as Jackson
do support it which is really handy. So switching from Gson to Jackson for JSON
handling we'll be usefull.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11572) camel-lumberjack component doesn't restart
[
https://issues.apache.org/jira/browse/CAMEL-11572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096191#comment-16096191
]
ASF GitHub Bot commented on CAMEL-11572:
GitHub user adessaigne opened a pull request:
https://github.com/apache/camel/pull/1838
CAMEL-11572 - Fix camel-lumberjack component lifecycle
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/adessaigne/camel CAMEL-11572
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1838.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 #1838
commit 6492e714c92189d75f48af9d5f1988e086524ca4
Author: Antoine DESSAIGNE
Date: 2017-07-21T12:35:56Z
CAMEL-11572 - Fix camel-lumberjack component lifecycle
> camel-lumberjack component doesn't restart
> --
>
> Key: CAMEL-11572
> URL: https://issues.apache.org/jira/browse/CAMEL-11572
> Project: Camel
> Issue Type: Bug
>Reporter: Antoine DESSAIGNE
>
> Hello.
> There's an issue in the {{camel-lumberjack}} component lifecycle preventing
> it from restarting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11572) camel-lumberjack component doesn't restart
Antoine DESSAIGNE created CAMEL-11572:
-
Summary: camel-lumberjack component doesn't restart
Key: CAMEL-11572
URL: https://issues.apache.org/jira/browse/CAMEL-11572
Project: Camel
Issue Type: Bug
Reporter: Antoine DESSAIGNE
Hello.
There's an issue in the {{camel-lumberjack}} component lifecycle preventing it
from restarting.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (CAMEL-11553) Upgrade to Brave 4
[
https://issues.apache.org/jira/browse/CAMEL-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radek Mensik updated CAMEL-11553:
-
Comment: was deleted
(was: Sure, but deprecated classes: _com.github.kristofa.brave.Brave_ is
deprecated and should be used _brave.Tracing_ and there is few more...
)
> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
> Issue Type: Task
> Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Kevin Earls
>Priority: Minor
>
> It would be nice to have up to date library not using deprecated code,
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526 INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging.
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 ->
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of
> _com.github.kristofa.brave.Sampler_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11553) Upgrade to Brave 4
[
https://issues.apache.org/jira/browse/CAMEL-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096182#comment-16096182
]
Radek Mensik commented on CAMEL-11553:
--
Sure, but deprecated classes: _com.github.kristofa.brave.Brave_ is deprecated
and should be used _brave.Tracing_ and there is few more...
> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
> Issue Type: Task
> Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Kevin Earls
>Priority: Minor
>
> It would be nice to have up to date library not using deprecated code,
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526 INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging.
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 ->
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of
> _com.github.kristofa.brave.Sampler_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11553) Upgrade to Brave 4
[
https://issues.apache.org/jira/browse/CAMEL-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096180#comment-16096180
]
Radek Mensik commented on CAMEL-11553:
--
Sure, but deprecated classes: com.github.kristofa.brave.Brave is deprecated and
should be used _brave.Tracing_ and there is few more...
> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
> Issue Type: Task
> Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Kevin Earls
>Priority: Minor
>
> It would be nice to have up to date library not using deprecated code,
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526 INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging.
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 ->
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of
> _com.github.kristofa.brave.Sampler_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11455) Automatic transform String to DBObject after previous conversion error
[ https://issues.apache.org/jira/browse/CAMEL-11455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096172#comment-16096172 ] Claus Ibsen commented on CAMEL-11455: - This is a little bit bigger problem due how bad those type converters was written from the beginning. So some of the tests was just passing even if there was type conversion errors that was just ignored and WARN logged. > Automatic transform String to DBObject after previous conversion error > -- > > Key: CAMEL-11455 > URL: https://issues.apache.org/jira/browse/CAMEL-11455 > Project: Camel > Issue Type: Bug > Components: camel-mongodb, camel-mongodb3 >Affects Versions: 2.19.1 >Reporter: Fabrizio Spataro >Assignee: Fabrizio Spataro > Fix For: 2.20.0, 2.19.3 > > Attachments: jsonFormatterDisappear.zip > > > Hello, > i found a bug. To reproduce it you can execute the code (see attachment file). > The bug is simple: > After an invalid conversion, the automatic String -> JSON transformation used > to put a document into MongoDB collection, fail! > Application flow: > # First document can be convert to JSON, Mongodb create a document (correct) > # Second document has an error, Mongodb cannot create a document (correct) > # Third document can be convert to JSON but Mongodb cannot create a document > into collection because automatic conversion is broken!!! (BUG) > Kings regards -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11455) Automatic transform String to DBObject after previous conversion error
[ https://issues.apache.org/jira/browse/CAMEL-11455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-11455: Fix Version/s: (was: 2.19.2) 2.19.3 > Automatic transform String to DBObject after previous conversion error > -- > > Key: CAMEL-11455 > URL: https://issues.apache.org/jira/browse/CAMEL-11455 > Project: Camel > Issue Type: Bug > Components: camel-mongodb, camel-mongodb3 >Affects Versions: 2.19.1 >Reporter: Fabrizio Spataro >Assignee: Fabrizio Spataro > Fix For: 2.20.0, 2.19.3 > > Attachments: jsonFormatterDisappear.zip > > > Hello, > i found a bug. To reproduce it you can execute the code (see attachment file). > The bug is simple: > After an invalid conversion, the automatic String -> JSON transformation used > to put a document into MongoDB collection, fail! > Application flow: > # First document can be convert to JSON, Mongodb create a document (correct) > # Second document has an error, Mongodb cannot create a document (correct) > # Third document can be convert to JSON but Mongodb cannot create a document > into collection because automatic conversion is broken!!! (BUG) > Kings regards -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11554) ServiceNow : add meta data extension to retrieve table's structure
[ https://issues.apache.org/jira/browse/CAMEL-11554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-11554 started by Luca Burgazzoli. --- > ServiceNow : add meta data extension to retrieve table's structure > -- > > Key: CAMEL-11554 > URL: https://issues.apache.org/jira/browse/CAMEL-11554 > Project: Camel > Issue Type: New Feature > Components: camel-servicenow >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 2.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11550) Component extensions
[
https://issues.apache.org/jira/browse/CAMEL-11550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-11550 started by Luca Burgazzoli.
---
> Component extensions
>
>
> Key: CAMEL-11550
> URL: https://issues.apache.org/jira/browse/CAMEL-11550
> Project: Camel
> Issue Type: New Feature
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>Priority: Minor
> Fix For: 2.20.0
>
>
> Some time ago we have introduced the PIngCheck aka ComponentVerifier
> interface that extends the functionality of a component by providing a way to
> validate the uri options but it would be nice to have a generic way for a
> component to expose extensions so we can have something like:
> {code:java}
> class Component {
> List getExtensions();
> Optional getExtension(Class
> type);
> }
> {code}
> So i.e. we can add a meta-data extension to grab the tables description of
> ServiceNow
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-11482:
Fix Version/s: (was: 2.19.2)
2.19.3
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
> Fix For: 2.20.0, 2.19.3
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11553) Upgrade to Brave 4
[
https://issues.apache.org/jira/browse/CAMEL-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16096015#comment-16096015
]
Kevin Earls commented on CAMEL-11553:
-
Hi [~cipous] can you explain what you mean here? We are already using brave
4.5.1 https://github.com/apache/camel/blob/master/parent/pom.xml#L101
> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
> Issue Type: Task
> Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Kevin Earls
>Priority: Minor
>
> It would be nice to have up to date library not using deprecated code,
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526 INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging.
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 ->
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of
> _com.github.kristofa.brave.Sampler_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-5356) CXF endpoint doesn't play nice with doTry/doCatch
[
https://issues.apache.org/jira/browse/CAMEL-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095955#comment-16095955
]
Jens Kleine-Herzbruch commented on CAMEL-5356:
--
cxf-bundle no longer exists with CXF 3.x. You probably need
{code}
org.apache.cxf
cxf-rt-transports-http-jetty
${cxf.version}
{code}
> CXF endpoint doesn't play nice with doTry/doCatch
> -
>
> Key: CAMEL-5356
> URL: https://issues.apache.org/jira/browse/CAMEL-5356
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.8.3
>Reporter: Jens Granseuer
>Assignee: Önder Sezgin
> Fix For: Future
>
> Attachments: camelTryCatch.zip
>
>
> When using a CXF client endpoint to call a web service via SOAP/HTTP there
> are two possible error scenarios:
> 1) The call fails immediately with an exception (e.g. because the service is
> down/the address is wrong)
> 2) The call "succeeds" but returns a SOAP fault. This could also signal an
> error condition to the application.
> Currently, using doTry/doCatch doesn't work properly in either scenario
> because, apprently, the CXF endpoint nulls the message when receiving an
> exception or fault.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11553) Upgrade to Brave 4
[
https://issues.apache.org/jira/browse/CAMEL-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Earls reassigned CAMEL-11553:
---
Assignee: Kevin Earls
> Upgrade to Brave 4
> --
>
> Key: CAMEL-11553
> URL: https://issues.apache.org/jira/browse/CAMEL-11553
> Project: Camel
> Issue Type: Task
> Components: camel-zipkin
>Affects Versions: 2.19.1
>Reporter: Radek Mensik
>Assignee: Kevin Earls
>Priority: Minor
>
> It would be nice to have up to date library not using deprecated code,
> because:
> Brave v. 4 allows you to use _brave.Tracing_ so one can easily register
> https://github.com/openzipkin/brave/tree/master/context/slf4j which allows
> you to have in each log line info about spans:
> {code:java}
> 2017-07-17 17:44:08.526 INFO [proxy,b805c5edbe362a7c,b805c5edbe362a7c,true]
> {code}
> Then it is easy to copy and use span id to zipkin UI in case of debugging.
> (btw currently there is Long value of span instead of Hexadecimal printed).
> There is possibility to overlap with version 3 and 4 ->
> https://github.com/openzipkin/brave/tree/master/brave#upgrading-from-brave-3
> so this could be good start.
> Also _brave.sampler.Sampler_ should be used in stead of
> _com.github.kristofa.brave.Sampler_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-5356) CXF endpoint doesn't play nice with doTry/doCatch
[
https://issues.apache.org/jira/browse/CAMEL-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095920#comment-16095920
]
Önder Sezgin commented on CAMEL-5356:
-
I tried to run the test with latest versions
as pom below
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
jar
de.dz.camel
trycatch-test
1.0
UTF-8
1.8
1.8
2.18.4
3.1.12
junit
junit
4.8.2
org.apache.camel
camel-cxf
${camel.version}
org.apache.camel
camel-spring
${camel.version}
org.apache.cxf
cxf-bundle
${cxf.version}
org.slf4j
slf4j-api
1.6.1
org.slf4j
slf4j-log4j12
1.6.1
junit
junit
test
org.apache.camel
camel-cxf
org.apache.camel
camel-spring
org.slf4j
slf4j-api
org.slf4j
slf4j-log4j12
runtime
org.apache.maven.plugins
maven-compiler-plugin
3.6.1
${java.source.version}
${java.target.version}
org.apache.maven.plugins
maven-surefire-plugin
2.20
org.apache.maven.plugins
maven-surefire-plugin
**/*Test.java
{code}
Have not debugged deeply? Anyone has an initial idea by the first look?
org.apache.camel.RuntimeCamelException:
org.apache.camel.FailedToCreateRouteException: Failed to create route
tryCatchRoute: Route(tryCatchRoute)[[From[cxf:bean:routerEP]] -> [ConvertBo...
because of ServiceConstructionException
at
org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1779)
at
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:138)
at
org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:353)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:167)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
at
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:383)
at
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:337)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:882)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:545)
at
org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
at
org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:83)
at de.dz.camel.test.TryCatchTest.setup(TryCatchTest.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefor
