[jira] [Created] (CAMEL-7940) Disable SSL security protocol by default
Willem Jiang created CAMEL-7940: --- Summary: Disable SSL security protocol by default Key: CAMEL-7940 URL: https://issues.apache.org/jira/browse/CAMEL-7940 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0, 2.13.2 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Camel SSLContextParameters doesn't disable the SSL protocol by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7941) Expose private variables as JSON for camel-swagger
Espen Tjonneland created CAMEL-7941:
---
Summary: Expose private variables as JSON for camel-swagger
Key: CAMEL-7941
URL: https://issues.apache.org/jira/browse/CAMEL-7941
Project: Camel
Issue Type: Improvement
Components: camel-swagger
Affects Versions: 2.14.0
Reporter: Espen Tjonneland
Priority: Minor
Consider the following class:
@ApiModel(value = MyDTO , description = My data transporter)
public class MyDTO {
@ApiModelProperty(value = This is a private field)
private String myPrivateField;
}
Swagger will not document the class as JSON. I am unsure if this is happening
in camel-core, or if this is a problem with Swagger. However, the behavior is
inconsistent with e.g. Gson, which handles private fields just fine. Instead it
relies on annotations for how the class variables should be exposed.
Would it be possible to have this variable exposed by default even though it is
private, and instead rely on annotations for deciding how to expose the
variables (like Gson does).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7942) Support Oauth, Ouath2 OpenID client to request token
Charles Moulliard created CAMEL-7942: Summary: Support Oauth, Ouath2 OpenID client to request token Key: CAMEL-7942 URL: https://issues.apache.org/jira/browse/CAMEL-7942 Project: Camel Issue Type: New Feature Reporter: Charles Moulliard Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7942) Support Oauth, Ouath2 OpenID client to request token
[ https://issues.apache.org/jira/browse/CAMEL-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charles Moulliard updated CAMEL-7942: - Description: Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) for OpenID was: Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) Support Oauth, Ouath2 OpenID client to request token -- Key: CAMEL-7942 URL: https://issues.apache.org/jira/browse/CAMEL-7942 Project: Camel Issue Type: New Feature Reporter: Charles Moulliard Apache Camel does not provide any security layer to support OAuth, OAuth2 or OpenID specifications to obtain a token, refresh it and maintain the existing tokens in a cache. Such a security layer should be interesting for the camel-cxf, camel-jetty, camel-http, REST DSL components ... The Apache OLTU project (https://oltu.apache.org/) could be used to support OAuth, OAuth2 and OpenID4java (https://code.google.com/p/openid4java/) for OpenID -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179793#comment-14179793 ] Colm O hEigeartaigh commented on CAMEL-7895: Thanks Christian! Colm. Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Christian Müller Priority: Minor Fix For: 2.13.3, 2.14.1, 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
Kevin Earls created CAMEL-7943: -- Summary: Add jackson core dependency to camel-dropbox pom Key: CAMEL-7943 URL: https://issues.apache.org/jira/browse/CAMEL-7943 Project: Camel Issue Type: Bug Reporter: Kevin Earls Priority: Minor camel-dropbox has a dependency on the dropbox sdks, which has a dependency on jackson-core version[2.2,2.3)/version. This can cause build failures such as Failed to execute goal on project camel-dropbox: Could not resolve dependencies for project org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT - [Help 2] depending on what repos you are using. We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
[ https://issues.apache.org/jira/browse/CAMEL-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179822#comment-14179822 ] ASF GitHub Bot commented on CAMEL-7943: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/307 CAMEL-7943 added explicit dependency for jackson-core You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7943 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/307.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 #307 commit 128da0928f2e41b4760753d228c21dc6b101aa9b Author: Kevin Earls ke...@kevinearls.com Date: 2014-10-22T11:35:27Z CAMEL-7943 added explicit dependency for jackson-core Add jackson core dependency to camel-dropbox pom Key: CAMEL-7943 URL: https://issues.apache.org/jira/browse/CAMEL-7943 Project: Camel Issue Type: Bug Reporter: Kevin Earls Priority: Minor camel-dropbox has a dependency on the dropbox sdks, which has a dependency on jackson-core version[2.2,2.3)/version. This can cause build failures such as Failed to execute goal on project camel-dropbox: Could not resolve dependencies for project org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT - [Help 2] depending on what repos you are using. We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
[ https://issues.apache.org/jira/browse/CAMEL-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179864#comment-14179864 ] ASF GitHub Bot commented on CAMEL-7943: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/307 Add jackson core dependency to camel-dropbox pom Key: CAMEL-7943 URL: https://issues.apache.org/jira/browse/CAMEL-7943 Project: Camel Issue Type: Bug Reporter: Kevin Earls Priority: Minor camel-dropbox has a dependency on the dropbox sdks, which has a dependency on jackson-core version[2.2,2.3)/version. This can cause build failures such as Failed to execute goal on project camel-dropbox: Could not resolve dependencies for project org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT - [Help 2] depending on what repos you are using. We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-7834: --- Assignee: Willem Jiang create a docker events endpoint --- Key: CAMEL-7834 URL: https://issues.apache.org/jira/browse/CAMEL-7834 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: Willem Jiang Docker provides a REST API to query events (for containers starting and stopping etc): https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events it'd be nice to support a simple camel component to make it easier to consume docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7940) Disable SSL security protocol by default
[ https://issues.apache.org/jira/browse/CAMEL-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7940. - Resolution: Fixed Applied the patch into camel master, camel-2.14.x and camel-2.13.x branches. Disable SSL security protocol by default Key: CAMEL-7940 URL: https://issues.apache.org/jira/browse/CAMEL-7940 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.2, 2.14.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Camel SSLContextParameters doesn't disable the SSL protocol by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179885#comment-14179885 ] Willem Jiang commented on CAMEL-7834: - Applied the patch into master branch with thanks to Andy. create a docker events endpoint --- Key: CAMEL-7834 URL: https://issues.apache.org/jira/browse/CAMEL-7834 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: Willem Jiang Docker provides a REST API to query events (for containers starting and stopping etc): https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events it'd be nice to support a simple camel component to make it easier to consume docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7944) Remove camel-jira /RealJIRATest.java
Kevin Earls created CAMEL-7944: -- Summary: Remove camel-jira /RealJIRATest.java Key: CAMEL-7944 URL: https://issues.apache.org/jira/browse/CAMEL-7944 Project: Camel Issue Type: Bug Reporter: Kevin Earls This should not ever have been checked in. I will create a pull request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6399) hazelcast - route policy for having one route being master, and others as slaves
[ https://issues.apache.org/jira/browse/CAMEL-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179934#comment-14179934 ] Nathan Jensen commented on CAMEL-6399: -- Locks are tied to threads (the thread that locks must do the unlock) so if that is an issue you could apply the same concept with Semaphores. See http://stackoverflow.com/questions/19767328/in-hazelcast-is-it-possible-to-use-clustered-locks-that-do-not-care-about-the and http://docs.hazelcast.org/docs/3.3/javadoc/com/hazelcast/core/ISemaphore.html hazelcast - route policy for having one route being master, and others as slaves Key: CAMEL-6399 URL: https://issues.apache.org/jira/browse/CAMEL-6399 Project: Camel Issue Type: New Feature Components: camel-hazelcast Reporter: Claus Ibsen Fix For: Future We should look into adding a route policy functionality to camel-hazelcast. So people can use it clustered Camel apps. And have only one node run the route. And if that node dies, then another becomes master. Hazelcast may have som way of support this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7945) SMPP connector as consumer stops camel context
Tomas Hanus created CAMEL-7945: -- Summary: SMPP connector as consumer stops camel context Key: CAMEL-7945 URL: https://issues.apache.org/jira/browse/CAMEL-7945 Project: Camel Issue Type: Bug Components: camel-smpp Affects Versions: 2.13.2 Reporter: Tomas Hanus I try to use SMPP component as producer and consumer to send SMS and PUSH SMS (MMS) to SMSC/receive delivery notifications or SMS from mobile devices. But still if SMSC is down camel context will shut down, and also all other context, so camel cannot start up. Affect version is camel 2.13.2 and only consumer. Producer is OK and parameter lazySessionCreation=true works well, but not for consumer. Any idea how to solve that? Probably it has to do with CAMEL-3853 issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7946) Backward compatibility of RoutingSlip/RecipientList statement is violated
Tomas Hanus created CAMEL-7946: -- Summary: Backward compatibility of RoutingSlip/RecipientList statement is violated Key: CAMEL-7946 URL: https://issues.apache.org/jira/browse/CAMEL-7946 Project: Camel Issue Type: Bug Affects Versions: 2.13.2 Reporter: Tomas Hanus Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (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:all-tabpanel ] Willem Jiang reassigned CAMEL-7938: --- Assignee: Willem Jiang 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 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] [Created] (CAMEL-7947) Support to set SSLContext in the camel-restlet
Willem Jiang created CAMEL-7947: --- Summary: Support to set SSLContext in the camel-restlet Key: CAMEL-7947 URL: https://issues.apache.org/jira/browse/CAMEL-7947 Project: Camel Issue Type: Improvement Components: camel-restlet Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.15.0 We cannot setup the SSLContext for the camel-restlet component now. It could be helpful if we can pass the sslContextParameters reference through the restlet endpoint uri. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-4494) Allow replyTo message header to be different from actual reply queue
[ https://issues.apache.org/jira/browse/CAMEL-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-4494. - Resolution: Fixed Fix Version/s: 2.15.0 Merged the patch into camel master branch with thanks to Jens. Allow replyTo message header to be different from actual reply queue Key: CAMEL-4494 URL: https://issues.apache.org/jira/browse/CAMEL-4494 Project: Camel Issue Type: New Feature Components: camel-jms Affects Versions: 2.8.1 Reporter: Jens Granseuer Assignee: Willem Jiang Fix For: 2.15.0 Attachments: camel-jms-replyto.diff, camel-jms-replyto2.diff, camel-jms-replyto2.diff We have an application that acts as a JMS client in the following setup: * a local queue manager (L) with queues for request (L.REQUEST) and reply (L.REPLY) messages * a remote queue manager (R) with queues for request (R.REQUEST) and reply (R.REPLY) messages The remote queue manager is unknown to the client application, and messages sent to L.REQUEST are automatically forwarded to R.REQUEST. Similarly, there is a server application listening on R.REQUEST, posting responses in R.REPLY. The local queue manager is unknown to the server application. Messages sent to R.REPLY are automatically forwarded to L.REPLY. The client needs to put message in L.REQUEST and receive the reply in L.REPLY. However, in the message header it must set R.REPLY as the reply queue because L.REPLY is not known to the server application. The Camel JMS component currently doesn't seem to support this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
