[jira] [Commented] (CAMEL-7938) Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part
[ https://issues.apache.org/jira/browse/CAMEL-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596183#comment-14596183 ] ASF GitHub Bot commented on CAMEL-7938: --- Github user steveardis closed the pull request at: https://github.com/apache/camel/pull/305 Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part Key: CAMEL-7938 URL: https://issues.apache.org/jira/browse/CAMEL-7938 Project: Camel Issue Type: Bug Components: camel-crypto Affects Versions: 2.11.1 Reporter: Steve Ardis Assignee: Willem Jiang Fix For: 2.13.0 If a message has multiple PGPPublicKeyEncryptedData (meaning, multiple recipients), PGPDataFormat fails to decrypt the message (unless our key is the first PGPPublicKeyEncryptedData element). Said differently, if a message is encrypted for recipient A and B (and the encrypted parts are in that order) and we are recipient B, the message fails to decrypt. This definitely affected version 2.11.1. Looking at the latest version of the same files, this is most likely still an issue. The fix in the patch that will be supplied is currently being used in our application, but unfortunately I do not have a test case available. I will create a pull-request on Github shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8790) Kafka producer hard coded to use Strings
[
https://issues.apache.org/jira/browse/CAMEL-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14596291#comment-14596291
]
Mark Mindenhall commented on CAMEL-8790:
Any timeframe on merging this? Also, I noticed the fix version is 2.16.0
only...please merge into 2.15.x as well. Thanks!
Kafka producer hard coded to use Strings
Key: CAMEL-8790
URL: https://issues.apache.org/jira/browse/CAMEL-8790
Project: Camel
Issue Type: Improvement
Components: camel-kafka
Affects Versions: 2.14.2, 2.15.2, 2.16.0
Reporter: Mark Mindenhall
Assignee: Willem Jiang
Fix For: 2.16.0
Attachments:
0001-CAMEL-8790-Fix-for-Kafka-producer-hard-coded-to-use-.patch
Kafka natively supports two encoders for messages:
# {{kafka.serializer.DefaultEncoder}} - encodes as byte arrays
# {{kafka.serializer.StringEncoder}} - encodes as Strings
Camel-kafka exposes settings to select the encoder (({{serializerClass}} and
{{keySerializerClass}}), but the
{{org.apache.camel.component.kafka.KafkaProducer}} class hard-codes String
for both the key and value types. This results in a {{ClassCastException}}
when using the {{DefaultDecoder}}.
The attached patch fixes this as follows (conforming to kafka itself):
* If no {{serializerClass}} option is specified, the {{DefaultDecoder}} is
used.
* If no {{keySerializerClass}} option is specified, the same encoder as
{{serializerClass}} is used
This fix shouldn't break any existing code, as there was not previously a
default setting (i.e., {{StringEncoder}} always had to be specified).
I created the patch against master, but it should backport easily to 2.15.x
and 2.14.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8838) Setting HttpConnectionManager Override Property in URI using HttpClientParams is not working
[ https://issues.apache.org/jira/browse/CAMEL-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak updated CAMEL-8838: -- Issue Type: Bug (was: Improvement) Setting HttpConnectionManager Override Property in URI using HttpClientParams is not working Key: CAMEL-8838 URL: https://issues.apache.org/jira/browse/CAMEL-8838 Project: Camel Issue Type: Bug Components: camel-http Affects Versions: 2.13.2, 2.15.0, 2.15.2 Reporter: Deepak Labels: camel, http Hi, When we pass HttpClientParams in EndPoint URI, to override HttpConnectionManager class, the HttpComponent is not considering the overridden parameter, Example URL https://myapplication.com/myappservice/?bridgeEndpoint=truethrowExceptionOnFailure=falsehttpClient.connectionManagerClass=org.apache.commons.httpclient.SimpleHttpConnectionManager In org.apache.camel.component.http.HttpComponent, if there is no bean injection of httpConnectionManager class, by default a new instance of MultiThreadedHttpConnectionManager class is created. In HttpComponent class, while constructing the HttpEndPoint, the same above HttpConnection Manager class is sent as reference. In HttpEndPoint class, createHttpClient method, although all the Http client params are considered, HttpConnectionManager class sent by the HttpClient Params is not considered. Please clarify or fix it. HttpClient answer = new HttpClient(getClientParams()); // Line Number 110 answer.setHttpConnectionManager(httpConnectionManager); // Line Number 144 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8838) Setting HttpConnectionManager Override Property in URI using HttpClientParams is not working
[ https://issues.apache.org/jira/browse/CAMEL-8838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Deepak updated CAMEL-8838: -- Issue Type: Improvement (was: Bug) Setting HttpConnectionManager Override Property in URI using HttpClientParams is not working Key: CAMEL-8838 URL: https://issues.apache.org/jira/browse/CAMEL-8838 Project: Camel Issue Type: Improvement Components: camel-http Affects Versions: 2.13.2, 2.15.0, 2.15.2 Reporter: Deepak Labels: camel, http Hi, When we pass HttpClientParams in EndPoint URI, to override HttpConnectionManager class, the HttpComponent is not considering the overridden parameter, Example URL https://myapplication.com/myappservice/?bridgeEndpoint=truethrowExceptionOnFailure=falsehttpClient.connectionManagerClass=org.apache.commons.httpclient.SimpleHttpConnectionManager In org.apache.camel.component.http.HttpComponent, if there is no bean injection of httpConnectionManager class, by default a new instance of MultiThreadedHttpConnectionManager class is created. In HttpComponent class, while constructing the HttpEndPoint, the same above HttpConnection Manager class is sent as reference. In HttpEndPoint class, createHttpClient method, although all the Http client params are considered, HttpConnectionManager class sent by the HttpClient Params is not considered. Please clarify or fix it. HttpClient answer = new HttpClient(getClientParams()); // Line Number 110 answer.setHttpConnectionManager(httpConnectionManager); // Line Number 144 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8890) camel-salesforce-maven-plugin: Unable to generate DTOs due to new encrypted field
Simon Delfab created CAMEL-8890:
---
Summary: camel-salesforce-maven-plugin: Unable to generate DTOs
due to new encrypted field
Key: CAMEL-8890
URL: https://issues.apache.org/jira/browse/CAMEL-8890
Project: Camel
Issue Type: Bug
Components: camel-salesforce
Affects Versions: 2.15.2
Reporter: Simon Delfab
The maven plugin is failing to generate the DTOs. It appears that Salesforce
has recently introduced a new boolean field call encrypted to the
'DescribeSObjectResult' object [1,2]
The fix is to modify the
org.apache.camel.component.salesforce.api.dto.SObjectField and add the
following:
private Boolean encrypted;
public Boolean getEncrypted() {
return encrypted;
}
public void setEncrypted(Boolean encrypted) {
this.encrypted = encrypted;
}
With this change the DTOs are generated. However, not sure if there is anything
else which needs to be done.
Btw, I am surprised that this new field causes a problem because the default
API version Camel-Salesforce is configured to is 33.0 and this new field
appears in 34.0.
[1]
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_calls_describesobjects_describesobjectresult.htm#topic-title
[2]
http://releasenotes.docs.salesforce.com/en-us/summer15/release-notes/rn_security_platform_encryption.htm
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8891) MVEL link on page http://camel.apache.org/mvel.html outdated
Martin Lichtin created CAMEL-8891: - Summary: MVEL link on page http://camel.apache.org/mvel.html outdated Key: CAMEL-8891 URL: https://issues.apache.org/jira/browse/CAMEL-8891 Project: Camel Issue Type: Improvement Components: documentation Reporter: Martin Lichtin Priority: Minor The MVEL link on page http://camel.apache.org/mvel.html is outdated. Can you update link to where MVEL is documented? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8790) Kafka producer hard coded to use Strings
[
https://issues.apache.org/jira/browse/CAMEL-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597201#comment-14597201
]
Willem Jiang commented on CAMEL-8790:
-
It's a new feature, we normally don't add a new feature to the patched release
branch.
I will take a look at this issue this week.
Kafka producer hard coded to use Strings
Key: CAMEL-8790
URL: https://issues.apache.org/jira/browse/CAMEL-8790
Project: Camel
Issue Type: Improvement
Components: camel-kafka
Affects Versions: 2.14.2, 2.15.2, 2.16.0
Reporter: Mark Mindenhall
Assignee: Willem Jiang
Fix For: 2.16.0
Attachments:
0001-CAMEL-8790-Fix-for-Kafka-producer-hard-coded-to-use-.patch
Kafka natively supports two encoders for messages:
# {{kafka.serializer.DefaultEncoder}} - encodes as byte arrays
# {{kafka.serializer.StringEncoder}} - encodes as Strings
Camel-kafka exposes settings to select the encoder (({{serializerClass}} and
{{keySerializerClass}}), but the
{{org.apache.camel.component.kafka.KafkaProducer}} class hard-codes String
for both the key and value types. This results in a {{ClassCastException}}
when using the {{DefaultDecoder}}.
The attached patch fixes this as follows (conforming to kafka itself):
* If no {{serializerClass}} option is specified, the {{DefaultDecoder}} is
used.
* If no {{keySerializerClass}} option is specified, the same encoder as
{{serializerClass}} is used
This fix shouldn't break any existing code, as there was not previously a
default setting (i.e., {{StringEncoder}} always had to be specified).
I created the patch against master, but it should backport easily to 2.15.x
and 2.14.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
