[jira] [Assigned] (CAMEL-12619) camel-swagger-java - Add support for 3.0 spec
[ https://issues.apache.org/jira/browse/CAMEL-12619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CAMEL-12619: Assignee: Freeman Yue Fang > camel-swagger-java - Add support for 3.0 spec > - > > Key: CAMEL-12619 > URL: https://issues.apache.org/jira/browse/CAMEL-12619 > Project: Camel > Issue Type: New Feature > Components: camel-swagger >Reporter: Claus Ibsen >Assignee: Freeman Yue Fang >Priority: Major > Labels: gsoc2019 > Fix For: 3.x > > > Not sure if we can make swagger v3 generate v2 spec files, so we can be 100% > backwards compatible. But v3 openapi 3.0 spec is a different maven GAV so its > maybe not an easy upgrade. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14156.
-
Resolution: Fixed
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 2.24.3, 3.0.0, 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14163) Support for multiple request query parameters in Rest component
[
https://issues.apache.org/jira/browse/CAMEL-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart updated CAMEL-14163:
--
Fix Version/s: 3.0.0.RC4
2.25.0
> Support for multiple request query parameters in Rest component
> ---
>
> Key: CAMEL-14163
> URL: https://issues.apache.org/jira/browse/CAMEL-14163
> Project: Camel
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.18.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC4
>
>
> The RestProducer doesn't have a way for specifying multiple query parameters.
> Given a header value that's a collection of values the resulting query
> parameter will be a joining of those values with the comma separator.
> Given that the query parameter can be specified multiple times, it is more
> common to have the parameter specified for each value of the collection
> rather than a single parameter with the coma-separated list of values.
> For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
> property {{queryParameters}} set to {{status=\{status\}}}, and on the message
> header the {{status}} is a collection or array of values (e.g.
> {{["available", "pending"]}}), the resulting URI path will be
> {{/v2/pet/findByStatus?status=available,pending}}.
> I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
> indicate that multiple query parameters should be provided instead of the
> coma-separated values.
> Perhaps something like {{status=\{status*\}}} as we already have
> {{status=\{status?\}}} to signify optional parameters. This would generate
> the URI path as {{/v2/pet/findByStatus?status=available=pending}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14163) Support for multiple request query parameters in Rest component
[
https://issues.apache.org/jira/browse/CAMEL-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart resolved CAMEL-14163.
---
Resolution: Fixed
> Support for multiple request query parameters in Rest component
> ---
>
> Key: CAMEL-14163
> URL: https://issues.apache.org/jira/browse/CAMEL-14163
> Project: Camel
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.18.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC4
>
>
> The RestProducer doesn't have a way for specifying multiple query parameters.
> Given a header value that's a collection of values the resulting query
> parameter will be a joining of those values with the comma separator.
> Given that the query parameter can be specified multiple times, it is more
> common to have the parameter specified for each value of the collection
> rather than a single parameter with the coma-separated list of values.
> For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
> property {{queryParameters}} set to {{status=\{status\}}}, and on the message
> header the {{status}} is a collection or array of values (e.g.
> {{["available", "pending"]}}), the resulting URI path will be
> {{/v2/pet/findByStatus?status=available,pending}}.
> I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
> indicate that multiple query parameters should be provided instead of the
> coma-separated values.
> Perhaps something like {{status=\{status*\}}} as we already have
> {{status=\{status?\}}} to signify optional parameters. This would generate
> the URI path as {{/v2/pet/findByStatus?status=available=pending}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14156:
Fix Version/s: 3.0.0
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 2.24.3, 3.0.0, 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14156:
Priority: Major (was: Critical)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 2.24.3, 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?focusedWorklogId=340750=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-340750
]
ASF GitHub Bot logged work on CAMEL-14156:
--
Author: ASF GitHub Bot
Created on: 08/Nov/19 21:14
Start Date: 08/Nov/19 21:14
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3328:
[CAMEL-14156] Avoid NPE with endpoint is null in JmsBinding
URL: https://github.com/apache/camel/pull/3328
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: 340750)
Time Spent: 20m (was: 10m)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14163) Support for multiple request query parameters in Rest component
[
https://issues.apache.org/jira/browse/CAMEL-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970561#comment-16970561
]
Zoran Regvart commented on CAMEL-14163:
---
Actually I found out that with a small tweak to the way query parameter values
are passed, that is without forcing them to convert to Strings, the support in
{{URISupport::createQueryString}} generates the correct URI. So no need for any
special indicator for this case.
> Support for multiple request query parameters in Rest component
> ---
>
> Key: CAMEL-14163
> URL: https://issues.apache.org/jira/browse/CAMEL-14163
> Project: Camel
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.18.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> The RestProducer doesn't have a way for specifying multiple query parameters.
> Given a header value that's a collection of values the resulting query
> parameter will be a joining of those values with the comma separator.
> Given that the query parameter can be specified multiple times, it is more
> common to have the parameter specified for each value of the collection
> rather than a single parameter with the coma-separated list of values.
> For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
> property {{queryParameters}} set to {{status=\{status\}}}, and on the message
> header the {{status}} is a collection or array of values (e.g.
> {{["available", "pending"]}}), the resulting URI path will be
> {{/v2/pet/findByStatus?status=available,pending}}.
> I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
> indicate that multiple query parameters should be provided instead of the
> coma-separated values.
> Perhaps something like {{status=\{status*\}}} as we already have
> {{status=\{status?\}}} to signify optional parameters. This would generate
> the URI path as {{/v2/pet/findByStatus?status=available=pending}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14155) xpath throws NPE if body is null when saxon is used as JAXP implementation
[
https://issues.apache.org/jira/browse/CAMEL-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-14155:
--
Description:
despite [XPath API
spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context
{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote}Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined.
{quote}
So in case of xpath expression is executed against a null body or header, it
throws an NPE
was:
despite [XPath API
spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote} Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined. {quote}
> xpath throws NPE if body is null when saxon is used as JAXP implementation
> --
>
> Key: CAMEL-14155
> URL: https://issues.apache.org/jira/browse/CAMEL-14155
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Reporter: Luigi De Masi
>Priority: Major
>
> despite [XPath API
> spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
> states:
>
> {quote}If a null value is provided for item, an empty document will be used
> for the context
> {quote}
> saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
> is null, from [saxon
> javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
>
> {quote}Contrary to the interface specification, Saxon does not supply an
> empty document when the value is null. This is because XPath 2.0 allows the
> context item to be "absent" (null). So Saxon executes the XPath expression
> with the context item undefined.
> {quote}
>
> So in case of xpath expression is executed against a null body or header, it
> throws an NPE
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14155) xpath throws NPE if body is null when saxon is used as JAXP implementation
[
https://issues.apache.org/jira/browse/CAMEL-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-14155:
--
Description:
despite [XPath API
spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context
{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote}Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined.
{quote}
So in case of xpath expression is executed against a null body or header,
saxon throws an NPE
was:
despite [XPath API
spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context
{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote}Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined.
{quote}
So in case of xpath expression is executed against a null body or header, it
throws an NPE
> xpath throws NPE if body is null when saxon is used as JAXP implementation
> --
>
> Key: CAMEL-14155
> URL: https://issues.apache.org/jira/browse/CAMEL-14155
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Reporter: Luigi De Masi
>Priority: Major
>
> despite [XPath API
> spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
> states:
>
> {quote}If a null value is provided for item, an empty document will be used
> for the context
> {quote}
> saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
> is null, from [saxon
> javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
>
> {quote}Contrary to the interface specification, Saxon does not supply an
> empty document when the value is null. This is because XPath 2.0 allows the
> context item to be "absent" (null). So Saxon executes the XPath expression
> with the context item undefined.
> {quote}
>
> So in case of xpath expression is executed against a null body or header,
> saxon throws an NPE
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14163) Support for multiple request query parameters in Rest component
[
https://issues.apache.org/jira/browse/CAMEL-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart updated CAMEL-14163:
--
Description:
The RestProducer doesn't have a way for specifying multiple query parameters.
Given a header value that's a collection of values the resulting query
parameter will be a joining of those values with the comma separator.
Given that the query parameter can be specified multiple times, it is more
common to have the parameter specified for each value of the collection rather
than a single parameter with the coma-separated list of values.
For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
property {{queryParameters}} set to {{status=\{status\}}}, and on the message
header the {{status}} is a collection or array of values (e.g. {{["available",
"pending"]}}), the resulting URI path will be
{{/v2/pet/findByStatus?status=available,pending}}.
I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
indicate that multiple query parameters should be provided instead of the
coma-separated values.
Perhaps something like {{status=\{status*\}}} as we already have
{{status=\{status?\}}} to signify optional parameters. This would generate the
URI path as {{/v2/pet/findByStatus?status=available=pending}}.
was:
The RestProducer doesn't have a way for specifying multiple query parameters.
Given a header value that's a collection of values the resulting query
parameter will be a joining of those values with the comma separator.
Given that the query parameter can be specified multiple times, it is more
common to have the parameter specified for each value of the collection rather
than a single parameter with the coma-separated list of values.
For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
property {{queryParameters}} set to {{status={status}}}, and on the message
header the {{status}} is a collection or array of values (e.g. {{["available",
"pending"]}}), the resulting URI path will be
{{/v2/pet/findByStatus?status=available,pending}}.
I think we could extemd the syntax of the placeholder (the {{{status}}}) to
indicate that multiple query parameters should be provided instead of the
coma-separated values.
Perhaps something like {{status={status*}}} as we already have
{{status={status?}}} to signify optional parameters. This would generate the
URI path as {{/v2/pet/findByStatus?status=available=pending}}.
> Support for multiple request query parameters in Rest component
> ---
>
> Key: CAMEL-14163
> URL: https://issues.apache.org/jira/browse/CAMEL-14163
> Project: Camel
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.18.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> The RestProducer doesn't have a way for specifying multiple query parameters.
> Given a header value that's a collection of values the resulting query
> parameter will be a joining of those values with the comma separator.
> Given that the query parameter can be specified multiple times, it is more
> common to have the parameter specified for each value of the collection
> rather than a single parameter with the coma-separated list of values.
> For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
> property {{queryParameters}} set to {{status=\{status\}}}, and on the message
> header the {{status}} is a collection or array of values (e.g.
> {{["available", "pending"]}}), the resulting URI path will be
> {{/v2/pet/findByStatus?status=available,pending}}.
> I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
> indicate that multiple query parameters should be provided instead of the
> coma-separated values.
> Perhaps something like {{status=\{status*\}}} as we already have
> {{status=\{status?\}}} to signify optional parameters. This would generate
> the URI path as {{/v2/pet/findByStatus?status=available=pending}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14163) Support for multiple request query parameters in Rest component
[
https://issues.apache.org/jira/browse/CAMEL-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart updated CAMEL-14163:
--
Description:
The RestProducer doesn't have a way for specifying multiple query parameters.
Given a header value that's a collection of values the resulting query
parameter will be a joining of those values with the comma separator.
Given that the query parameter can be specified multiple times, it is more
common to have the parameter specified for each value of the collection rather
than a single parameter with the coma-separated list of values.
For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
property {{queryParameters}} set to {{status={status}}}, and on the message
header the {{status}} is a collection or array of values (e.g. {{["available",
"pending"]}}), the resulting URI path will be
{{/v2/pet/findByStatus?status=available,pending}}.
I think we could extemd the syntax of the placeholder (the {{{status}}}) to
indicate that multiple query parameters should be provided instead of the
coma-separated values.
Perhaps something like {{status={status*}}} as we already have
{{status={status?}}} to signify optional parameters. This would generate the
URI path as {{/v2/pet/findByStatus?status=available=pending}}.
was:
The RestProducer doesn't have a way for specifying multiple query parameters.
Given a header value that's a collection of values the resulting query
parameter will be a joining of those values with the comma separator.
Given that the query parameter can be specified multiple times, it is more
common to have the parameter specified for each value of the collection rather
than a single parameter with the coma-separated list of values.
For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
property {{queryParameters}} set to {{status=\{status\}}}, and on the message
header the {{status}} is a collection or array of values (e.g. {{["available",
"pending"]}}), the resulting URI will be
{{/v2/pet/findByStatus?status=available,pending}}.
I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
indicate that multiple query parameters should be provided instead of the
coma-separated values.
Perhaps something like {{status=\{status*\}}} as we already have
{{status=\{status?\}}} to signify optional parameters.
> Support for multiple request query parameters in Rest component
> ---
>
> Key: CAMEL-14163
> URL: https://issues.apache.org/jira/browse/CAMEL-14163
> Project: Camel
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.18.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Major
>
> The RestProducer doesn't have a way for specifying multiple query parameters.
> Given a header value that's a collection of values the resulting query
> parameter will be a joining of those values with the comma separator.
> Given that the query parameter can be specified multiple times, it is more
> common to have the parameter specified for each value of the collection
> rather than a single parameter with the coma-separated list of values.
> For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
> property {{queryParameters}} set to {{status={status}}}, and on the message
> header the {{status}} is a collection or array of values (e.g.
> {{["available", "pending"]}}), the resulting URI path will be
> {{/v2/pet/findByStatus?status=available,pending}}.
> I think we could extemd the syntax of the placeholder (the {{{status}}}) to
> indicate that multiple query parameters should be provided instead of the
> coma-separated values.
> Perhaps something like {{status={status*}}} as we already have
> {{status={status?}}} to signify optional parameters. This would generate the
> URI path as {{/v2/pet/findByStatus?status=available=pending}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14163) Support for multiple request query parameters in Rest component
Zoran Regvart created CAMEL-14163:
-
Summary: Support for multiple request query parameters in Rest
component
Key: CAMEL-14163
URL: https://issues.apache.org/jira/browse/CAMEL-14163
Project: Camel
Issue Type: Improvement
Components: rest
Affects Versions: 2.18.0
Reporter: Zoran Regvart
Assignee: Zoran Regvart
The RestProducer doesn't have a way for specifying multiple query parameters.
Given a header value that's a collection of values the resulting query
parameter will be a joining of those values with the comma separator.
Given that the query parameter can be specified multiple times, it is more
common to have the parameter specified for each value of the collection rather
than a single parameter with the coma-separated list of values.
For example, endpoint URI of {{rest:GET:/v2/:pet/findByStatus}} and endpoint
property {{queryParameters}} set to {{status=\{status\}}}, and on the message
header the {{status}} is a collection or array of values (e.g. {{["available",
"pending"]}}), the resulting URI will be
{{/v2/pet/findByStatus?status=available,pending}}.
I think we could extemd the syntax of the placeholder (the {{\{status\}}}) to
indicate that multiple query parameters should be provided instead of the
coma-separated values.
Perhaps something like {{status=\{status*\}}} as we already have
{{status=\{status?\}}} to signify optional parameters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14160) Update default algorithms in the Crypto Component/DataFormat
[ https://issues.apache.org/jira/browse/CAMEL-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-14160. - Resolution: Fixed > Update default algorithms in the Crypto Component/DataFormat > > > Key: CAMEL-14160 > URL: https://issues.apache.org/jira/browse/CAMEL-14160 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.0.0 > > > This task is to update the default algorithms in the Crypto > Component/DataFormat. For the Crypto Component, the default algorithm will > change from SHA1WithDSA -> SHA256withRSA. For the Crypto DataFormat, the > default algorithm will change from "DES/CBC/PKCS5Padding" just to null, thus > forcing the client to specify a default algorithm. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?focusedWorklogId=340573=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-340573
]
ASF GitHub Bot logged work on CAMEL-14156:
--
Author: ASF GitHub Bot
Created on: 08/Nov/19 15:58
Start Date: 08/Nov/19 15:58
Worklog Time Spent: 10m
Work Description: jbonofre commented on pull request #3328: [CAMEL-14156]
Avoid NPE with endpoint is null in JmsBinding
URL: https://github.com/apache/camel/pull/3328
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: 340573)
Remaining Estimate: 0h
Time Spent: 10m
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14160) Update default algorithms in the Crypto Component/DataFormat
[ https://issues.apache.org/jira/browse/CAMEL-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CAMEL-14160: Description: This task is to update the default algorithms in the Crypto Component/DataFormat. For the Crypto Component, the default algorithm will change from SHA1WithDSA -> SHA256withRSA. For the Crypto DataFormat, the default algorithm will change from "DES/CBC/PKCS5Padding" just to null, thus forcing the client to specify a default algorithm. (was: This task is to update the default algorithms in the Crypto Component/DataFormat. For the Crypto Component, the default algorithm will change from SHA1WithDSA -> SHA256withRSA. For the Crypto DataFormat, the default algorithm will change from) > Update default algorithms in the Crypto Component/DataFormat > > > Key: CAMEL-14160 > URL: https://issues.apache.org/jira/browse/CAMEL-14160 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.0.0 > > > This task is to update the default algorithms in the Crypto > Component/DataFormat. For the Crypto Component, the default algorithm will > change from SHA1WithDSA -> SHA256withRSA. For the Crypto DataFormat, the > default algorithm will change from "DES/CBC/PKCS5Padding" just to null, thus > forcing the client to specify a default algorithm. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14162) camel-stream - When using http url then data is not sent over the wire
[ https://issues.apache.org/jira/browse/CAMEL-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14162. - Fix Version/s: 2.24.3 Resolution: Fixed > camel-stream - When using http url then data is not sent over the wire > -- > > Key: CAMEL-14162 > URL: https://issues.apache.org/jira/browse/CAMEL-14162 > Project: Camel > Issue Type: Bug > Components: camel-stream >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > When using JDKs URLConnection it wont send data until you start to read the > input stream. So we need to add logic to do this so we force a flush and send > data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14162) camel-stream - When using http url then data is not sent over the wire
[ https://issues.apache.org/jira/browse/CAMEL-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14162: Priority: Minor (was: Major) > camel-stream - When using http url then data is not sent over the wire > -- > > Key: CAMEL-14162 > URL: https://issues.apache.org/jira/browse/CAMEL-14162 > Project: Camel > Issue Type: Bug > Components: camel-stream >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > When using JDKs URLConnection it wont send data until you start to read the > input stream. So we need to add logic to do this so we force a flush and send > data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14162) camel-stream - When using http url then data is not sent over the wire
Claus Ibsen created CAMEL-14162: --- Summary: camel-stream - When using http url then data is not sent over the wire Key: CAMEL-14162 URL: https://issues.apache.org/jira/browse/CAMEL-14162 Project: Camel Issue Type: Bug Components: camel-stream Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.0.0, 2.25.0 When using JDKs URLConnection it wont send data until you start to read the input stream. So we need to add logic to do this so we force a flush and send data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14139) Camel Undertow does not provide an option to use the producer as the "Host" header when bridging two http endpoints
[
https://issues.apache.org/jira/browse/CAMEL-14139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-14139:
-
Fix Version/s: (was: 2.24.3)
(was: 2.25.0)
> Camel Undertow does not provide an option to use the producer as the "Host"
> header when bridging two http endpoints
> ---
>
> Key: CAMEL-14139
> URL: https://issues.apache.org/jira/browse/CAMEL-14139
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 3.0.0.RC3
>Reporter: Avinash Dongre
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Camel undertow always propagates the same host header from source to target.
> There is no option to disable this.
> {code:xml}
>
> http://localhost:8189"/>
>
> http://localhost:8289"/>
>
>
> http://localhost:8289"/>
>
>
> {code}
>
> Result:
> {code:xml}
> 2019-11-05 12:43:54.738 INFO 30967 --- [ XNIO-2 task-1] route1 : Source
> localhost:8189
> 2019-11-05 12:43:54.789 INFO 30967 --- [ XNIO-3 task-1] route2 : Target
> localhost:8189
> {code}
> Expected:
> {code:xml}
> 2019-11-05 12:43:54.738 INFO 30967 --- [ XNIO-2 task-1] route1 : Source
> localhost:8189
> 2019-11-05 12:43:54.789 INFO 30967 --- [ XNIO-3 task-1] route2 : Target
> localhost:8289
> {code}
> An option to disable the preservation of the original host is present in
> camel-http
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14139) Camel Undertow does not provide an option to use the producer as the "Host" header when bridging two http endpoints
[
https://issues.apache.org/jira/browse/CAMEL-14139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-14139.
--
Resolution: Fixed
> Camel Undertow does not provide an option to use the producer as the "Host"
> header when bridging two http endpoints
> ---
>
> Key: CAMEL-14139
> URL: https://issues.apache.org/jira/browse/CAMEL-14139
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 3.0.0.RC3
>Reporter: Avinash Dongre
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Camel undertow always propagates the same host header from source to target.
> There is no option to disable this.
> {code:xml}
>
> http://localhost:8189"/>
>
> http://localhost:8289"/>
>
>
> http://localhost:8289"/>
>
>
> {code}
>
> Result:
> {code:xml}
> 2019-11-05 12:43:54.738 INFO 30967 --- [ XNIO-2 task-1] route1 : Source
> localhost:8189
> 2019-11-05 12:43:54.789 INFO 30967 --- [ XNIO-3 task-1] route2 : Target
> localhost:8189
> {code}
> Expected:
> {code:xml}
> 2019-11-05 12:43:54.738 INFO 30967 --- [ XNIO-2 task-1] route1 : Source
> localhost:8189
> 2019-11-05 12:43:54.789 INFO 30967 --- [ XNIO-3 task-1] route2 : Target
> localhost:8289
> {code}
> An option to disable the preservation of the original host is present in
> camel-http
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14121) NullPointerException for kubernetes-config-maps
[
https://issues.apache.org/jira/browse/CAMEL-14121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino resolved CAMEL-14121.
--
Resolution: Won't Fix
> NullPointerException for kubernetes-config-maps
> ---
>
> Key: CAMEL-14121
> URL: https://issues.apache.org/jira/browse/CAMEL-14121
> Project: Camel
> Issue Type: Improvement
>Reporter: imran raza khan
>Assignee: Andrea Cosentino
>Priority: Major
>
> I have simple route like below
> {color:#505f79} from("timer://ipc?repeatCount=1"){color}
>
> {color:#505f79}.toF("kubernetes-config-maps://%s?oauthToken=%s=true=yq-qa=my-config-map",
> host, authToken){color}
> {color:#505f79} .to("log:my?showAll=true=true");{color}
>
> if configmap with the name of "my-config-map" is not available in project it
> throws NullPointerexception with long trace, i think ApacheCamel should throw
> catched exception with one line
>
> [mel-1) thread #2 - timer://ipc] DefaultErrorHandler ERROR Failed
> delivery for (MessageId: ID-NB-118-1572539384582-0-2 on ExchangeId:
> ID-NB-118-1572539384582-0-1). Exhausted after delivery attempt: 1 caught:
> java.lang.NullPointerException[mel-1) thread #2 - timer://ipc]
> DefaultErrorHandler ERROR Failed delivery for (MessageId:
> ID-NB-118-1572539384582-0-2 on ExchangeId: ID-NB-118-1572539384582-0-1).
> Exhausted after delivery attempt: 1 caught: java.lang.NullPointerException
> Message
> History---RouteId
> ProcessorId Processor
> Elapsed (ms)[route1 ]
> [route1 ] [timer://ipc?repeatCount=1
> ] [ 7][route1 ] [to1 ]
> [kubernetes-config-maps://https://m.devokd.younicos.local:8443?oauthToken=6QTHP]
> [ 5]
> Stacktrace---java.lang.NullPointerException:
> null at
> org.apache.camel.component.kubernetes.config_maps.KubernetesConfigMapsProducer.process(KubernetesConfigMapsProducer.java:62)
> ~[camel-kubernetes-2.24.2.jar:2.24.2] at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:178)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:445)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:173)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:197)
> [camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:79)
> [camel-core-2.24.2.jar:2.24.2] at
> java.util.TimerThread.mainLoop(Timer.java:555) [?:1.8.0_162] at
> java.util.TimerThread.run(Timer.java:505) [?:1.8.0_162][mel-1) thread #2 -
> timer://ipc] TimerConsumer WARN Error processing exchange.
> Exchange[ID-NB-118-1572539384582-0-1]. Caused by:
> [java.lang.NullPointerException - null]java.lang.NullPointerException: null
> at
> org.apache.camel.component.kubernetes.config_maps.KubernetesConfigMapsProducer.process(KubernetesConfigMapsProducer.java:62)
> ~[camel-kubernetes-2.24.2.jar:2.24.2] at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:178)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:445)
> ~[camel-core-2.24.2.jar:2.24.2] at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:173)
> ~[camel-core-2.24.2.jar:2.24.2] at
[jira] [Commented] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970217#comment-16970217
]
Andrea Cosentino commented on CAMEL-14156:
--
I'm removing 2.23.5
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Cosentino updated CAMEL-14156:
-
Fix Version/s: (was: 2.23.5)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970212#comment-16970212
]
Jean-Baptiste Onofré commented on CAMEL-14156:
--
I'm porting the fix on other branches.
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970209#comment-16970209
]
Jean-Baptiste Onofré commented on CAMEL-14156:
--
It has been fixed on {{master}}:
{code}
if (headerName.equals("JMSCorrelationID") && (endpoint == null ||
!endpoint.isUseMessageIDAsCorrelationID()))
{code}
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated CAMEL-14156:
-
Fix Version/s: (was: 3.0.0.RC4)
(was: 3.0.0)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 2.25.0, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14140) Remove global dependency on outdated guava
[ https://issues.apache.org/jira/browse/CAMEL-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970132#comment-16970132 ] Andrea Cosentino commented on CAMEL-14140: -- I reverted this fix, even by hardcoding the version, using a common version of guava all around doesn't work for some of them, for example guava-eventbus and nsq. It must stay as-is. I'm sorry. > Remove global dependency on outdated guava > -- > > Key: CAMEL-14140 > URL: https://issues.apache.org/jira/browse/CAMEL-14140 > Project: Camel > Issue Type: Task > Components: camel-cassandraql >Reporter: Thomas Diesler >Assignee: Thomas Diesler >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, camel comes with google-guava-version=19.0 which contains a number > of deprecated APIs that have been removed in 20.x. AFAICS, cassandra-3.x is > the only component that depends on these deprecated guava APIs. This > dependency has been removed in cassandra-4.x, which is currently in alpha. In > WildFly-Camel, I confirmed that it should generally be possible to update to > guava-26.x as long as cassandra can still use 19.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (CAMEL-14140) Remove global dependency on outdated guava
[ https://issues.apache.org/jira/browse/CAMEL-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reopened CAMEL-14140: -- > Remove global dependency on outdated guava > -- > > Key: CAMEL-14140 > URL: https://issues.apache.org/jira/browse/CAMEL-14140 > Project: Camel > Issue Type: Task > Components: camel-cassandraql >Reporter: Thomas Diesler >Assignee: Thomas Diesler >Priority: Major > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, camel comes with google-guava-version=19.0 which contains a number > of deprecated APIs that have been removed in 20.x. AFAICS, cassandra-3.x is > the only component that depends on these deprecated guava APIs. This > dependency has been removed in cassandra-4.x, which is currently in alpha. In > WildFly-Camel, I confirmed that it should generally be possible to update to > guava-26.x as long as cassandra can still use 19.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14161) Remove default key from camel-shiro
[ https://issues.apache.org/jira/browse/CAMEL-14161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-14161. - Resolution: Fixed > Remove default key from camel-shiro > --- > > Key: CAMEL-14161 > URL: https://issues.apache.org/jira/browse/CAMEL-14161 > Project: Camel > Issue Type: Improvement > Components: camel-shiro >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.0.0 > > > We should remove the default encryption key from camel-shiro as it's not > secure. The user must specify an encryption key. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14161) Remove default key from camel-shiro
Colm O hEigeartaigh created CAMEL-14161: --- Summary: Remove default key from camel-shiro Key: CAMEL-14161 URL: https://issues.apache.org/jira/browse/CAMEL-14161 Project: Camel Issue Type: Improvement Components: camel-shiro Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.0.0 We should remove the default encryption key from camel-shiro as it's not secure. The user must specify an encryption key. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14157) Upgrade default signature algorithm for XML Signature to RSA-SHA256
[ https://issues.apache.org/jira/browse/CAMEL-14157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-14157. - Resolution: Fixed > Upgrade default signature algorithm for XML Signature to RSA-SHA256 > --- > > Key: CAMEL-14157 > URL: https://issues.apache.org/jira/browse/CAMEL-14157 > Project: Camel > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.0.0 > > > For the 3.0.0 release we should update the default signature algorithm for > XML Signature from RSA-SHA1 to RSA-SHA256. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14160) Update default algorithms in the Crypto Component/DataFormat
Colm O hEigeartaigh created CAMEL-14160: --- Summary: Update default algorithms in the Crypto Component/DataFormat Key: CAMEL-14160 URL: https://issues.apache.org/jira/browse/CAMEL-14160 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.0.0 This task is to update the default algorithms in the Crypto Component/DataFormat. For the Crypto Component, the default algorithm will change from SHA1WithDSA -> SHA256withRSA. For the Crypto DataFormat, the default algorithm will change from -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-12619) camel-swagger-java - Add support for 3.0 spec
[ https://issues.apache.org/jira/browse/CAMEL-12619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970033#comment-16970033 ] Claus Ibsen commented on CAMEL-12619: - We should create a new component camel-openapi - That are v3 spec. And then the older -swagger are for 2.0 and can then in the future be deprecated when that spec is no longer in use > camel-swagger-java - Add support for 3.0 spec > - > > Key: CAMEL-12619 > URL: https://issues.apache.org/jira/browse/CAMEL-12619 > Project: Camel > Issue Type: New Feature > Components: camel-swagger >Reporter: Claus Ibsen >Priority: Major > Labels: gsoc2019 > Fix For: 3.x > > > Not sure if we can make swagger v3 generate v2 spec files, so we can be 100% > backwards compatible. But v3 openapi 3.0 spec is a different maven GAV so its > maybe not an easy upgrade. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14159) camel-elytron - Security component
Claus Ibsen created CAMEL-14159: --- Summary: camel-elytron - Security component Key: CAMEL-14159 URL: https://issues.apache.org/jira/browse/CAMEL-14159 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: 3.x Maybe we can create a security component ala spring security where you can setup policies per route https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970027#comment-16970027 ] Omar Al-Safi commented on CAMEL-14152: -- +1 > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14158) camel-microprofile - Reactive Messaging component
Claus Ibsen created CAMEL-14158: --- Summary: camel-microprofile - Reactive Messaging component Key: CAMEL-14158 URL: https://issues.apache.org/jira/browse/CAMEL-14158 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen Fix For: 3.x We should look at adding a new camel component for MP reactive messaging spec https://github.com/eclipse/microprofile-reactive-messaging -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14150) Camel-exec: option to hide sensitive information in log
[ https://issues.apache.org/jira/browse/CAMEL-14150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14150. - Fix Version/s: 3.0.0 Resolution: Fixed Thanks for the PR > Camel-exec: option to hide sensitive information in log > --- > > Key: CAMEL-14150 > URL: https://issues.apache.org/jira/browse/CAMEL-14150 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Affects Versions: 3.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Fix For: 3.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > It's possible, that ExecCommand may contain sensitive information. These > commands are logged on level INFO during route execution. New configuration > parameter should be introduced, which will change the level of the log for > ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14157) Upgrade default signature algorithm for XML Signature to RSA-SHA256
Colm O hEigeartaigh created CAMEL-14157: --- Summary: Upgrade default signature algorithm for XML Signature to RSA-SHA256 Key: CAMEL-14157 URL: https://issues.apache.org/jira/browse/CAMEL-14157 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.0.0 For the 3.0.0 release we should update the default signature algorithm for XML Signature from RSA-SHA1 to RSA-SHA256. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14150) Camel-exec: option to hide sensitive information in log
[ https://issues.apache.org/jira/browse/CAMEL-14150?focusedWorklogId=340418=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-340418 ] ASF GitHub Bot logged work on CAMEL-14150: -- Author: ASF GitHub Bot Created on: 08/Nov/19 10:08 Start Date: 08/Nov/19 10:08 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3325: [CAMEL-14150] Camel-exec: option to hide sensitive information in log URL: https://github.com/apache/camel/pull/3325 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: 340418) Time Spent: 20m (was: 10m) > Camel-exec: option to hide sensitive information in log > --- > > Key: CAMEL-14150 > URL: https://issues.apache.org/jira/browse/CAMEL-14150 > Project: Camel > Issue Type: Improvement > Components: camel-exec >Affects Versions: 3.0.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > It's possible, that ExecCommand may contain sensitive information. These > commands are logged on level INFO during route execution. New configuration > parameter should be introduced, which will change the level of the log for > ExecCommand to DEBUG. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970010#comment-16970010
]
Andrea Cosentino commented on CAMEL-14156:
--
We won't release 2.23.x. there is no need to fix there
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-13750) Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
[
https://issues.apache.org/jira/browse/CAMEL-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned CAMEL-13750:
Assignee: Andrea Cosentino (was: Jean-Baptiste Onofré)
> Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
> --
>
> Key: CAMEL-13750
> URL: https://issues.apache.org/jira/browse/CAMEL-13750
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.1
>Reporter: Alvin Kwekel
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.23.4, 2.24.2, 3.0.0.RC1, 3.0.0, 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {noformat}
> +-++-++-+
> | | +-> Q1 +-> | | +-> Q3 +-> | |
> |A||B||C|
> | | <-+ Q2 <-+ | | <-+ Q4 <-+ | |
> +-++-++-+{noformat}
> JMS request goes from A to B to C and the reply back from C to B to A.
> A useMessageIDAsCorrelationID=false
> B useMessageIDAsCorrelationID=true
> C useMessageIDAsCorrelationID=false
> The JMSCorrelationID assigned by A is passed along to C via Camel message
> headers when useMessageIDAsCorrelationID is set on B's request. B is
> expecting the JMSMessageID to be used as JMSCorrelationID on the reply but
> since the JMSCorrelationID is actually provided, C could decide to give
> precedence to the JMSCorrelationID rendering B's message selector to not
> match.
> The only case this would work as expected is when C is also set to
> useMessageIDAsCorrelationID to always prefer the JMSMessageID. But consider
> situations where C is not under your control and/or implemented in a
> different technology than Camel.
> I'd argue the JMSCorrelationID should be made _null_ when the
> useMessageIDAsCorrelationID is set on a provider.
> I've created an example project to demonstrate the behavior:
> [https://github.com/alvinkwekel/camel-example-jmscorrelationid]
> This issue seems to be closely related to
> https://issues.apache.org/jira/browse/CAMEL-2249
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13750) Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
[
https://issues.apache.org/jira/browse/CAMEL-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970008#comment-16970008
]
Jean-Baptiste Onofré commented on CAMEL-13750:
--
A mistake, I was about to reopen it, but I finally create a new Jira. I'm
reassigning.
> Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
> --
>
> Key: CAMEL-13750
> URL: https://issues.apache.org/jira/browse/CAMEL-13750
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.1
>Reporter: Alvin Kwekel
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 2.23.4, 2.24.2, 3.0.0.RC1, 3.0.0, 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {noformat}
> +-++-++-+
> | | +-> Q1 +-> | | +-> Q3 +-> | |
> |A||B||C|
> | | <-+ Q2 <-+ | | <-+ Q4 <-+ | |
> +-++-++-+{noformat}
> JMS request goes from A to B to C and the reply back from C to B to A.
> A useMessageIDAsCorrelationID=false
> B useMessageIDAsCorrelationID=true
> C useMessageIDAsCorrelationID=false
> The JMSCorrelationID assigned by A is passed along to C via Camel message
> headers when useMessageIDAsCorrelationID is set on B's request. B is
> expecting the JMSMessageID to be used as JMSCorrelationID on the reply but
> since the JMSCorrelationID is actually provided, C could decide to give
> precedence to the JMSCorrelationID rendering B's message selector to not
> match.
> The only case this would work as expected is when C is also set to
> useMessageIDAsCorrelationID to always prefer the JMSMessageID. But consider
> situations where C is not under your control and/or implemented in a
> different technology than Camel.
> I'd argue the JMSCorrelationID should be made _null_ when the
> useMessageIDAsCorrelationID is set on a provider.
> I've created an example project to demonstrate the behavior:
> [https://github.com/alvinkwekel/camel-example-jmscorrelationid]
> This issue seems to be closely related to
> https://issues.apache.org/jira/browse/CAMEL-2249
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated CAMEL-14156:
-
Priority: Critical (was: Major)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Critical
> Fix For: 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
[
https://issues.apache.org/jira/browse/CAMEL-14156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated CAMEL-14156:
-
Issue Type: Bug (was: Task)
> JmsBinding assumes endpoint can't be null, but it can
> -
>
> Key: CAMEL-14156
> URL: https://issues.apache.org/jira/browse/CAMEL-14156
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4, 2.23.5
>
>
> CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
> {code}
> if (headerName.equals("JMSCorrelationID") &&
> !endpoint.isUseMessageIDAsCorrelationID()) {
> {code}
> As {{endpoint}} can be null (for instance if you just do {{new
> JmsBinding()}}), this change is wrong as it can throw
> {{NullPointerException}}.
> I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14156) JmsBinding assumes endpoint can't be null, but it can
Jean-Baptiste Onofré created CAMEL-14156:
Summary: JmsBinding assumes endpoint can't be null, but it can
Key: CAMEL-14156
URL: https://issues.apache.org/jira/browse/CAMEL-14156
Project: Camel
Issue Type: Task
Components: camel-activemq, camel-jms
Affects Versions: 2.24.2
Reporter: Jean-Baptiste Onofré
Assignee: Jean-Baptiste Onofré
Fix For: 2.23.5, 2.24.3, 3.0.0, 2.25.0, 3.0.0.RC4
CAMEL-13750 introduces a change checking the {{endpoint}} in {{JmsBinding}}:
{code}
if (headerName.equals("JMSCorrelationID") &&
!endpoint.isUseMessageIDAsCorrelationID()) {
{code}
As {{endpoint}} can be null (for instance if you just do {{new JmsBinding()}}),
this change is wrong as it can throw {{NullPointerException}}.
I'm fixing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-13750) Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
[
https://issues.apache.org/jira/browse/CAMEL-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970004#comment-16970004
]
Andrea Cosentino commented on CAMEL-13750:
--
[~jbonofre]Onofré why did you re-assign this?
> Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
> --
>
> Key: CAMEL-13750
> URL: https://issues.apache.org/jira/browse/CAMEL-13750
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.1
>Reporter: Alvin Kwekel
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 2.23.4, 2.24.2, 3.0.0.RC1, 3.0.0, 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {noformat}
> +-++-++-+
> | | +-> Q1 +-> | | +-> Q3 +-> | |
> |A||B||C|
> | | <-+ Q2 <-+ | | <-+ Q4 <-+ | |
> +-++-++-+{noformat}
> JMS request goes from A to B to C and the reply back from C to B to A.
> A useMessageIDAsCorrelationID=false
> B useMessageIDAsCorrelationID=true
> C useMessageIDAsCorrelationID=false
> The JMSCorrelationID assigned by A is passed along to C via Camel message
> headers when useMessageIDAsCorrelationID is set on B's request. B is
> expecting the JMSMessageID to be used as JMSCorrelationID on the reply but
> since the JMSCorrelationID is actually provided, C could decide to give
> precedence to the JMSCorrelationID rendering B's message selector to not
> match.
> The only case this would work as expected is when C is also set to
> useMessageIDAsCorrelationID to always prefer the JMSMessageID. But consider
> situations where C is not under your control and/or implemented in a
> different technology than Camel.
> I'd argue the JMSCorrelationID should be made _null_ when the
> useMessageIDAsCorrelationID is set on a provider.
> I've created an example project to demonstrate the behavior:
> [https://github.com/alvinkwekel/camel-example-jmscorrelationid]
> This issue seems to be closely related to
> https://issues.apache.org/jira/browse/CAMEL-2249
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-13750) Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
[
https://issues.apache.org/jira/browse/CAMEL-13750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned CAMEL-13750:
Assignee: Jean-Baptiste Onofré (was: Andrea Cosentino)
> Incoming JMSCorrelationID is passed along when useMessageIDAsCorrelationID
> --
>
> Key: CAMEL-13750
> URL: https://issues.apache.org/jira/browse/CAMEL-13750
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-jms
>Affects Versions: 2.24.1
>Reporter: Alvin Kwekel
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 2.23.4, 2.24.2, 3.0.0.RC1, 3.0.0, 2.25.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
>
> {noformat}
> +-++-++-+
> | | +-> Q1 +-> | | +-> Q3 +-> | |
> |A||B||C|
> | | <-+ Q2 <-+ | | <-+ Q4 <-+ | |
> +-++-++-+{noformat}
> JMS request goes from A to B to C and the reply back from C to B to A.
> A useMessageIDAsCorrelationID=false
> B useMessageIDAsCorrelationID=true
> C useMessageIDAsCorrelationID=false
> The JMSCorrelationID assigned by A is passed along to C via Camel message
> headers when useMessageIDAsCorrelationID is set on B's request. B is
> expecting the JMSMessageID to be used as JMSCorrelationID on the reply but
> since the JMSCorrelationID is actually provided, C could decide to give
> precedence to the JMSCorrelationID rendering B's message selector to not
> match.
> The only case this would work as expected is when C is also set to
> useMessageIDAsCorrelationID to always prefer the JMSMessageID. But consider
> situations where C is not under your control and/or implemented in a
> different technology than Camel.
> I'd argue the JMSCorrelationID should be made _null_ when the
> useMessageIDAsCorrelationID is set on a provider.
> I've created an example project to demonstrate the behavior:
> [https://github.com/alvinkwekel/camel-example-jmscorrelationid]
> This issue seems to be closely related to
> https://issues.apache.org/jira/browse/CAMEL-2249
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14152) Add RocksDB Aggregator to Camel
[ https://issues.apache.org/jira/browse/CAMEL-14152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16970002#comment-16970002 ] Andrea Cosentino commented on CAMEL-14152: -- Sounds good then. If legal will complain we'll move it to extra > Add RocksDB Aggregator to Camel > > > Key: CAMEL-14152 > URL: https://issues.apache.org/jira/browse/CAMEL-14152 > Project: Camel > Issue Type: New Feature >Reporter: Omar Al-Safi >Assignee: Omar Al-Safi >Priority: Minor > Fix For: 3.x > > > Although we have LevelDB Aggregator in Camel, I thought it will be as well > beneficial for users to have as well RocksDB Aggregator. Although RocksDB is > basically based on LevelDB, I think Facebook has done great optimizations on > it to have a good performance on sample data bigger than the machine's RAM. > I can work on it after we release 3.0.0 GA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14155) xpath throws NPE if body is null when saxon is used as JAXP implementation
[
https://issues.apache.org/jira/browse/CAMEL-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-14155:
--
Description:
despite [XPath API
spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote} Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined. {quote}
was:
despite [XPath API spec|
https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context\{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote} Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined.\{quote}
> xpath throws NPE if body is null when saxon is used as JAXP implementation
> --
>
> Key: CAMEL-14155
> URL: https://issues.apache.org/jira/browse/CAMEL-14155
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Reporter: Luigi De Masi
>Priority: Major
>
> despite [XPath API
> spec|https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
> states:
>
> {quote}If a null value is provided for item, an empty document will be used
> for the context{quote}
> saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
> is null, from [saxon
> javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
>
> {quote} Contrary to the interface specification, Saxon does not supply an
> empty document when the value is null. This is because XPath 2.0 allows the
> context item to be "absent" (null). So Saxon executes the XPath expression
> with the context item undefined. {quote}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14155) xpath throws NPE if body is null when saxon is used as JAXP implementation
[
https://issues.apache.org/jira/browse/CAMEL-14155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luigi De Masi updated CAMEL-14155:
--
Summary: xpath throws NPE if body is null when saxon is used as JAXP
implementation (was: xpath throws NPE if body is null when camel-saxon is used
as JAXP implementation)
> xpath throws NPE if body is null when saxon is used as JAXP implementation
> --
>
> Key: CAMEL-14155
> URL: https://issues.apache.org/jira/browse/CAMEL-14155
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Reporter: Luigi De Masi
>Priority: Major
>
> despite [XPath API spec|
> https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
> states:
> {quote}If a null value is provided for item, an empty document will be used
> for the context\{quote}
> saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
> is null, from [saxon
> javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
> {quote} Contrary to the interface specification, Saxon does not supply an
> empty document when the value is null. This is because XPath 2.0 allows the
> context item to be "absent" (null). So Saxon executes the XPath expression
> with the context item undefined.\{quote}
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14155) xpath throws NPE if body is null when camel-saxon is used as JAXP implementation
Luigi De Masi created CAMEL-14155:
-
Summary: xpath throws NPE if body is null when camel-saxon is used
as JAXP implementation
Key: CAMEL-14155
URL: https://issues.apache.org/jira/browse/CAMEL-14155
Project: Camel
Issue Type: Bug
Components: came-core
Reporter: Luigi De Masi
despite [XPath API spec|
https://docs.oracle.com/javase/8/docs/api/javax/xml/xpath/XPathExpression.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]
states:
{quote}If a null value is provided for item, an empty document will be used for
the context\{quote}
saxon, starting from 9.6, they decided to ignore it and throw NPE if the node
is null, from [saxon
javadoc|https://www.saxonica.com/html/documentation9.8/javadoc/net/sf/saxon/xpath/XPathExpressionImpl.html#evaluate-java.lang.Object-javax.xml.namespace.QName-]:
{quote} Contrary to the interface specification, Saxon does not supply an empty
document when the value is null. This is because XPath 2.0 allows the context
item to be "absent" (null). So Saxon executes the XPath expression with the
context item undefined.\{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14153) camel-main - Allow to specify constructor parameters
[
https://issues.apache.org/jira/browse/CAMEL-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16969935#comment-16969935
]
Claus Ibsen commented on CAMEL-14153:
-
This is a bit more complex as constructors can have several parameters and we
would need to convert to their type and also parse the input ala bean language
does.
> camel-main - Allow to specify constructor parameters
>
>
> Key: CAMEL-14153
> URL: https://issues.apache.org/jira/browse/CAMEL-14153
> Project: Camel
> Issue Type: New Feature
> Components: camel-main
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0
>
>
> For example when configuring jms with amq/qpid etc then they have constructor
> parameters
> {code}
> camel.component.jms.connection-factory=#class:org.apache.qpid.jms.JmsConnectionFactory("")
> {code}
> Where ("xxx") are constructor parameters
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14154) Add option to create cache if it doesn't exists in camel-infinispan
John Poth created CAMEL-14154: - Summary: Add option to create cache if it doesn't exists in camel-infinispan Key: CAMEL-14154 URL: https://issues.apache.org/jira/browse/CAMEL-14154 Project: Camel Issue Type: Improvement Components: camel-infinispan Affects Versions: 3.0.0.RC3 Reporter: John Poth It might be nice to have an option in camel-infinispan to create the cache if it doesn't exits. -- This message was sent by Atlassian Jira (v8.3.4#803005)
