[jira] [Commented] (CAMEL-7919) Add tests for camel-jira component
[ https://issues.apache.org/jira/browse/CAMEL-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181134#comment-14181134 ] ASF GitHub Bot commented on CAMEL-7919: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/310 CAMEL-7919 New tests for the camel-jira component You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7919A Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/310.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 #310 commit 9906985763e32a01f0b2dd1caa3d3f727e55660d Author: Kevin Earls ke...@kevinearls.com Date: 2014-10-23T08:40:03Z CAMEL-7919 New tests for the camel-jira component Add tests for camel-jira component -- Key: CAMEL-7919 URL: https://issues.apache.org/jira/browse/CAMEL-7919 Project: Camel Issue Type: Bug Reporter: Kevin Earls Assignee: Willem Jiang Priority: Minor The new camel-jira component needs tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7948) Add support for more/new encryption/signature algorithms
[ https://issues.apache.org/jira/browse/CAMEL-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CAMEL-7948: --- Attachment: camel-7948.patch Add support for more/new encryption/signature algorithms Key: CAMEL-7948 URL: https://issues.apache.org/jira/browse/CAMEL-7948 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Priority: Minor Attachments: camel-7948.patch See attached for a patch to support some new (to XML Security) digest algorithms such as RIPE-MD160 and SEED + CAMELLIA encryption algorithms. Also added a fairly comprehensive set of tests for different encryption/signature algorithms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CAMEL-7848) Netty-Http component: add support for registry's encoders and decoders
[ https://issues.apache.org/jira/browse/CAMEL-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaron A reopened CAMEL-7848: Estimated Complexity: Moderate (was: Unknown) Sorry for this late response. The fix did work properly in the netty-http component but there seem to be an issue with the netty4-http component. The decoder I set, HttpContentDecompressor, is not properly applied in the current 2.14.1 snapshot version. I managed to fix the issue by implementing my own ClientInitializerFactory which is a clone of HttpClientInitializerFactory with one small change: the following line pipeline.addLast(http, new HttpClientCodec()); should be placed before adding the encoders/decoders and not after. Please review my suggestion and see if you find it as the proper solution Thanks Netty-Http component: add support for registry's encoders and decoders -- Key: CAMEL-7848 URL: https://issues.apache.org/jira/browse/CAMEL-7848 Project: Camel Issue Type: New Feature Components: camel-netty-http Affects Versions: 2.14.0 Reporter: Yaron A Assignee: Willem Jiang Fix For: 2.14.1, 2.15.0 Currently the camel-netty component supports setting encoders decoders that enlisted in the registry. It will be very helpful to have this functionality similarly supported in the camel-netty-http component too. From what I saw, camel-netty's ClientPipelineFactory implementation (DefaultClientPipelineFactory) supports it in the getPipeline method but a similar implementation does not exist in camel-netty-http's ClientPipelineFactory implementation (HttpClientPipelineFactory). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7934) Camel-olingo2 should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde reassigned CAMEL-7934: --- Assignee: Dhiraj Bokde Camel-olingo2 should create https connections using SSLContextParameters Key: CAMEL-7934 URL: https://issues.apache.org/jira/browse/CAMEL-7934 Project: Camel Issue Type: Bug Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7933) Camel-apns should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde reassigned CAMEL-7933: --- Assignee: Dhiraj Bokde Camel-apns should create https connections using SSLContextParameters - Key: CAMEL-7933 URL: https://issues.apache.org/jira/browse/CAMEL-7933 Project: Camel Issue Type: Bug Components: camel-apns Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-apns uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7949) JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage
Aaron Whiteside created CAMEL-7949: -- Summary: JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage Key: CAMEL-7949 URL: https://issues.apache.org/jira/browse/CAMEL-7949 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.14.0 Reporter: Aaron Whiteside Priority: Critical JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage. Looking at the code, byte[] and InputStream conversion to BytesMessage could utilize camel's built in type conversion functionality and not reimplement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7950) SJMS's Producers creates a new session per message request, this is both a performance issue and problem when using transactions
Aaron Whiteside created CAMEL-7950: -- Summary: SJMS's Producers creates a new session per message request, this is both a performance issue and problem when using transactions Key: CAMEL-7950 URL: https://issues.apache.org/jira/browse/CAMEL-7950 Project: Camel Issue Type: Improvement Reporter: Aaron Whiteside SJMS's Producers creates a new Session per message request, this is both a performance issue and a problem when using transactions. Sessions should be cached in ThreadLocal for performance reasons. Of course you may want to limit the total number of cached sessions or even implement a stack/queue of sessions to reuse. As long as a new session isn't create for every single message produced to a Queue/Topic. Second the same session should be used for any consumption and production to any queues by a thread when transactions are enabled. If a single route is consuming from JMS and producing to JMS, one would expect the same session to be used to provide atomic consumption and production to the queues/topics involved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7951) No way to configure the ExchangeFormatter in RedeliveryErrorHandler (want to see the Exchange's properties by default)
Aaron Whiteside created CAMEL-7951: -- Summary: No way to configure the ExchangeFormatter in RedeliveryErrorHandler (want to see the Exchange's properties by default) Key: CAMEL-7951 URL: https://issues.apache.org/jira/browse/CAMEL-7951 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Aaron Whiteside No way to configure the ExchangeFormatter in RedeliveryErrorHandler (I want to see the Exchange's properties by default) Could be settable using a set method and/or looked up from the Registry with name supplied in the RedeliveryPolicyDefinition.. etc. Also I would ask if you could make the default behavior to print the Exchange's Properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7950) SJMS's Producers creates a new session per message request, this is both a performance issue and problem when using transactions
[ https://issues.apache.org/jira/browse/CAMEL-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Whiteside updated CAMEL-7950: --- Description: SJMS's Producers creates a new Session per message request, this is both a performance issue and a problem when using transactions. Sessions should be cached in ThreadLocal for performance reasons. Of course you may want to limit the total number of cached sessions or even implement a stack/queue of sessions to reuse. As long as a new session isn't created for every single message produced to a Queue/Topic. Second the same session should be used for any consumption and production to any queues by a thread when transactions are enabled. If a single route is consuming from JMS and producing to JMS, one would expect the same session to be used to provide atomic consumption and production to the queues/topics involved. was: SJMS's Producers creates a new Session per message request, this is both a performance issue and a problem when using transactions. Sessions should be cached in ThreadLocal for performance reasons. Of course you may want to limit the total number of cached sessions or even implement a stack/queue of sessions to reuse. As long as a new session isn't create for every single message produced to a Queue/Topic. Second the same session should be used for any consumption and production to any queues by a thread when transactions are enabled. If a single route is consuming from JMS and producing to JMS, one would expect the same session to be used to provide atomic consumption and production to the queues/topics involved. SJMS's Producers creates a new session per message request, this is both a performance issue and problem when using transactions Key: CAMEL-7950 URL: https://issues.apache.org/jira/browse/CAMEL-7950 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.14.0 Reporter: Aaron Whiteside SJMS's Producers creates a new Session per message request, this is both a performance issue and a problem when using transactions. Sessions should be cached in ThreadLocal for performance reasons. Of course you may want to limit the total number of cached sessions or even implement a stack/queue of sessions to reuse. As long as a new session isn't created for every single message produced to a Queue/Topic. Second the same session should be used for any consumption and production to any queues by a thread when transactions are enabled. If a single route is consuming from JMS and producing to JMS, one would expect the same session to be used to provide atomic consumption and production to the queues/topics involved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7952) Camel REST does not handle same path with differents VERBS
Pierre-Alban DEWITTE created CAMEL-7952:
---
Summary: Camel REST does not handle same path with differents VERBS
Key: CAMEL-7952
URL: https://issues.apache.org/jira/browse/CAMEL-7952
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Environment: ALL
Reporter: Pierre-Alban DEWITTE
If we had the same path with different verbs (GET, POST, DELETE) only one is
randomly choosen.
To reproduce this issue i just changed the route builder in
camel-example-servlet-rest-tomcat.
In UserRouteBuilder.java change the last statement of configure() method with
:
rest(/user).description(User rest service)
.consumes(application/json).produces(application/json)
.get(/name).description(GET).outTypeList(User.class)
.to(bean:userService?method=listUsers)
.post(/name).description(POST).to(bean:userService?method=listUsers)
.delete(/{name}).description(DELETE).to(bean:userService?method=listUsers)
;
After a quick debug it seams that the CamelServlet is fiiling a map of
HttpConsumer. The key is path so only last one can be used further.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
