[jira] [Assigned] (CAMEL-6460) camel-core-http - As a core component for http client and jetty
[ https://issues.apache.org/jira/browse/CAMEL-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6460: -- Assignee: Claus Ibsen > camel-core-http - As a core component for http client and jetty > --- > > Key: CAMEL-6460 > URL: https://issues.apache.org/jira/browse/CAMEL-6460 > Project: Camel > Issue Type: Improvement > Components: camel-http, camel-jetty >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > Today camel-jetty and camel-servlet requires camel-http, which has dependency > on http client 3.x. We should create a camel-http-core which the shared code, > and then let camel-http be the http client component only. And then allow > camel-servlet and camel-jetty to dep on camel-http-core and thus not bring in > http client 3.1 anymore. > See also > http://camel.465427.n5.nabble.com/camel-jetty-dependency-on-httpclient-3-tp5734180.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638270#comment-14638270 ] Claus Ibsen commented on CAMEL-9001: No we do not ship any kind of source code that uses 3rd party that do not adhere to the ASF policy. Neither should Camel Extra - eg users should safely assume its fine to use the software. It really sound like your component should NOT be at ASF or Camel Extra under the current license terms of that 3rd party JAR. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638263#comment-14638263 ] Daniel Pocock commented on CAMEL-9001: -- Just to clarify what I meant in (b) - could such components be built using some alternative profile in Maven, e.g. mvn -Pnonfreestuff and if somebody doesn't enable that profile, such things are not built? As long as such components don't end up becoming dependencies for essential parts of the project, this would give the user an option to build them in their own environment. I put some questions more specific to Camel-extra policy in CAMEX-69 > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638236#comment-14638236 ] Claus Ibsen commented on CAMEL-9001: b = no. The JAR is not optional, you have java imports in the source code. The compiler cannot compile if the JAR is missing and the code cannot either run at runtime without the JAR on the classpath. ASF does not do any tricks. You should be able to use the component as-is without having to install or do something extra to make it work. If that is required then ASF will not accept that. Only if the JAR is some 3rd party add-on that is not the primary function of the component it may be possible. See more details at http://www.apache.org/legal/resolved.html#optional > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638214#comment-14638214 ] Daniel Pocock commented on CAMEL-9001: -- There are two separate issues here: a) the license itself - that is available via a link from the POM. As the license title suggests, the license text does not meet the requirements of the open source community and none of that code can be copied into an Apache repository, that is fully understood b) the component for Camel. It is optional both at compile time and for distribution. If somebody chooses to make a build without this component, nothing else will break. Debian, for example, contains the FreeRADIUS package which includes an optional Oracle module, disabled with a compile option: https://sources.debian.net/src/freeradius/2.2.5%2Bdfsg-0.2/debian/rules/#L85 but the module source is still part of the source package and it is in the repository so people can manually enable it if they want to and if they have the non-free dependencies on their system. Could Camel simply flag such dependencies in the same way? > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[ https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638202#comment-14638202 ] Claus Ibsen commented on CAMEL-9002: What is the use case for this. Surely if you do your own velocity context then the default behavior no longer apply. > Headers set within velocity header are not saved when using custom > VelocityContext > -- > > Key: CAMEL-9002 > URL: https://issues.apache.org/jira/browse/CAMEL-9002 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.2 >Reporter: Chris Pimlott >Priority: Minor > Attachments: VelocityContextHeaderSetHeaderTest.java > > > Normally, any headers set within the velocity header are preserved as headers > on the out message. However, this does not work if you use your own > VelocityContext via the CamelVelocityContext. This is because > VelocityEndpoint relies on the fact that the "headers" entry in the velocity > context normally points directly to the current Exchange's in headers. This > is not likely true when using an existing velocity context. > A more foolproof solution might be to look for and explicitly copy any > updated headers from the velocity context to the out message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14638189#comment-14638189 ] Claus Ibsen commented on CAMEL-9001: Oh I think that we just pushed the problem to Camel Extra. Eg that project cannot include projects that uses an unknown or licenses that restrict their users etc. Camel Extra however can include a wider range of licenses such as GPL etc which we cannot here at ASF. It is not clear what the license is for that TWS api JAR. Maybe you can find the license or get in touch with that company so they can tell us, or maybe they can do a release which clearly states what the license is. Or maybe they would consider licensing it using a more known license - There are many FOSS licenses out today. The JAR of the TWS only has that comment in the -sources JAR. There is no LICENSE file or anything to indicate more details. It also seems that this IB license is divided into commercial vs non-commercial which is also problematic. Any users of ASF should be able to use the software for any way they like, whether its commercial or not etc. The same should really be the goal for Camel Extra too. If that company for example would re-license their API JAR in a compatible way then we are happy to include the camel component here. As its only the API JAR then its not their secret trading source code, but assuming only the code needed to make it easier to integrate with their software. And hence maybe that company is more willingly to consider a re-license or use some license that the FOSS communities can accept. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[ https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CAMEL-9002: - Priority: Minor (was: Major) > Headers set within velocity header are not saved when using custom > VelocityContext > -- > > Key: CAMEL-9002 > URL: https://issues.apache.org/jira/browse/CAMEL-9002 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.2 >Reporter: Chris Pimlott >Priority: Minor > Attachments: VelocityContextHeaderSetHeaderTest.java > > > Normally, any headers set within the velocity header are preserved as headers > on the out message. However, this does not work if you use your own > VelocityContext via the CamelVelocityContext. This is because > VelocityEndpoint relies on the fact that the "headers" entry in the velocity > context normally points directly to the current Exchange's in headers. This > is not likely true when using an existing velocity context. > A more foolproof solution might be to look for and explicitly copy any > updated headers from the velocity context to the out message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[
https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637935#comment-14637935
]
Chris Pimlott commented on CAMEL-9002:
--
Hmm, I realize now the proposed solution might not be so simple, since if we
are using a custom Velocity Context, there's no guarantee there actually is a
{{headers}} key that we should be looking for.
Another possible solution would be to allow the user to specify a {{Context}}
or {{Map}} of *additional* context variables that would be added to the default
auto-generated context.
> Headers set within velocity header are not saved when using custom
> VelocityContext
> --
>
> Key: CAMEL-9002
> URL: https://issues.apache.org/jira/browse/CAMEL-9002
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.2
>Reporter: Chris Pimlott
> Attachments: VelocityContextHeaderSetHeaderTest.java
>
>
> Normally, any headers set within the velocity header are preserved as headers
> on the out message. However, this does not work if you use your own
> VelocityContext via the CamelVelocityContext. This is because
> VelocityEndpoint relies on the fact that the "headers" entry in the velocity
> context normally points directly to the current Exchange's in headers. This
> is not likely true when using an existing velocity context.
> A more foolproof solution might be to look for and explicitly copy any
> updated headers from the velocity context to the out message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[
https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637934#comment-14637934
]
Chris Pimlott commented on CAMEL-9002:
--
Adding a test case that demonstrates this.
{{VelocityContextHelper.generateVelocityContext}} generates a velocity Context
the exact same way that {{VelocityEndpoint.onExchange}} does when none already
exists, but it doesn't work since it receives a different Exchange instance
than VelocityEndpoint does.
> Headers set within velocity header are not saved when using custom
> VelocityContext
> --
>
> Key: CAMEL-9002
> URL: https://issues.apache.org/jira/browse/CAMEL-9002
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.2
>Reporter: Chris Pimlott
> Attachments: VelocityContextHeaderSetHeaderTest.java
>
>
> Normally, any headers set within the velocity header are preserved as headers
> on the out message. However, this does not work if you use your own
> VelocityContext via the CamelVelocityContext. This is because
> VelocityEndpoint relies on the fact that the "headers" entry in the velocity
> context normally points directly to the current Exchange's in headers. This
> is not likely true when using an existing velocity context.
> A more foolproof solution might be to look for and explicitly copy any
> updated headers from the velocity context to the out message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[ https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CAMEL-9002: - Description: Normally, any headers set within the velocity header are preserved as headers on the out message. However, this does not work if you use your own VelocityContext via the CamelVelocityContext. This is because VelocityEndpoint relies on the fact that the "headers" entry in the velocity context normally points directly to the current Exchange's in headers. This is not likely true when using an existing velocity context. A more foolproof solution might be to look for and explicitly copy any updated headers from the velocity context to the out message. was: Normally, any headers set within the velocity header are preserved as headers on the out message. However, this does not work if you use your own VelocityContext via the CamelVelocityContext. This is because VelocityEndpoint relies on the fact that the "headers" entry in the velocity context normally points directly to the current Exchange's in headers. This is not likely true when using an existing velocity context. A more foolproof solution would be to explicitly copy any updated headers from the velocity context to the out message. > Headers set within velocity header are not saved when using custom > VelocityContext > -- > > Key: CAMEL-9002 > URL: https://issues.apache.org/jira/browse/CAMEL-9002 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.2 >Reporter: Chris Pimlott > Attachments: VelocityContextHeaderSetHeaderTest.java > > > Normally, any headers set within the velocity header are preserved as headers > on the out message. However, this does not work if you use your own > VelocityContext via the CamelVelocityContext. This is because > VelocityEndpoint relies on the fact that the "headers" entry in the velocity > context normally points directly to the current Exchange's in headers. This > is not likely true when using an existing velocity context. > A more foolproof solution might be to look for and explicitly copy any > updated headers from the velocity context to the out message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
[ https://issues.apache.org/jira/browse/CAMEL-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Pimlott updated CAMEL-9002: - Attachment: VelocityContextHeaderSetHeaderTest.java > Headers set within velocity header are not saved when using custom > VelocityContext > -- > > Key: CAMEL-9002 > URL: https://issues.apache.org/jira/browse/CAMEL-9002 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.2 >Reporter: Chris Pimlott > Attachments: VelocityContextHeaderSetHeaderTest.java > > > Normally, any headers set within the velocity header are preserved as headers > on the out message. However, this does not work if you use your own > VelocityContext via the CamelVelocityContext. This is because > VelocityEndpoint relies on the fact that the "headers" entry in the velocity > context normally points directly to the current Exchange's in headers. This > is not likely true when using an existing velocity context. > A more foolproof solution would be to explicitly copy any updated headers > from the velocity context to the out message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9002) Headers set within velocity header are not saved when using custom VelocityContext
Chris Pimlott created CAMEL-9002: Summary: Headers set within velocity header are not saved when using custom VelocityContext Key: CAMEL-9002 URL: https://issues.apache.org/jira/browse/CAMEL-9002 Project: Camel Issue Type: Bug Affects Versions: 2.15.2 Reporter: Chris Pimlott Normally, any headers set within the velocity header are preserved as headers on the out message. However, this does not work if you use your own VelocityContext via the CamelVelocityContext. This is because VelocityEndpoint relies on the fact that the "headers" entry in the velocity context normally points directly to the current Exchange's in headers. This is not likely true when using an existing velocity context. A more foolproof solution would be to explicitly copy any updated headers from the velocity context to the out message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637545#comment-14637545 ] Daniel Pocock commented on CAMEL-9001: -- I've now adapted the patch to camel-extras and raised an issue at: https://camel-extra.atlassian.net/browse/CAMEX-69 Please let me know about the wiki question and then I'll close this issue. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637447#comment-14637447 ] ASF GitHub Bot commented on CAMEL-9001: --- Github user dpocock closed the pull request at: https://github.com/apache/camel/pull/568 > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637414#comment-14637414 ] Daniel Pocock commented on CAMEL-9001: -- Yes, I agree that there are other options, like hosting it independently on Github The camel-extra link is a link to Google Code, should it now point to https://github.com/camel-extra/camel-extra or somewhere else and is that where the pull request should be? For those projects that live in camel-extra or independent repositories, what is the attitude to documenting them on the main wiki? I see other projects are there but if that is an anti-pattern please tell me. In any case, if I put this on the wiki I will include a comment about licensing. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637398#comment-14637398 ] Daniel Pocock commented on CAMEL-9001: -- Claus, can you also comment on the Camel project's attitude to API JARs, e.g. the Oracle vs Google issue? https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637402#comment-14637402 ] Claus Ibsen commented on CAMEL-9001: Your choice. It cannot be accepted here, sorry. The story should be that this is not a choice between ASF or Camel Extra, as if there is only 2 choices. There is plenty of other communities, and maybe having it independent at github is a better place to innovate faster and have quick releases and whatnot. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637377#comment-14637377 ] Daniel Pocock commented on CAMEL-9001: -- Under point 2 in the link http://camel.apache.org/add-new-component-guide.html it mentions the camel-extra repository - so does this belong there? > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[
https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637370#comment-14637370
]
Claus Ibsen commented on CAMEL-9001:
The code imports from that JAR don't it?
For example from the Camel component source code in the PR
{code}
+import com.ib.client.Contract;
+import com.ib.client.TickType;
+import com.ib.client.Types.MktDataType;
+import com.ib.client.Types.SecType;
+import com.ib.controller.ApiController.ITopMktDataHandler;
{code}
And if so that JAR uses a non valid license then we cannot accept this PR. If
this is the case please close the PR and this ticket.
> add TWS component
> -
>
> Key: CAMEL-9001
> URL: https://issues.apache.org/jira/browse/CAMEL-9001
> Project: Camel
> Issue Type: New Feature
>Affects Versions: 2.16.0
> Environment: all
>Reporter: Daniel Pocock
> Labels: features
>
> Add a component for the Interactive Brokers Trader Workstation (TWS) API
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[
https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637356#comment-14637356
]
Claus Ibsen commented on CAMEL-9001:
Please when submitting a new component, then do check for license compatability.
I am not sure what that TWS uses. But the -sources JAR had this header which
alerts me
{code}
/* Copyright (C) 2013 Interactive Brokers LLC. All rights reserved. This code
is subject to the terms
* and conditions of the IB API Non-Commercial License or the IB API Commercial
License, as applicable. */
{code}
You can see about what ASF license we can accept in this guide
http://camel.apache.org/add-new-component-guide.html
> add TWS component
> -
>
> Key: CAMEL-9001
> URL: https://issues.apache.org/jira/browse/CAMEL-9001
> Project: Camel
> Issue Type: New Feature
>Affects Versions: 2.16.0
> Environment: all
>Reporter: Daniel Pocock
> Labels: features
>
> Add a component for the Interactive Brokers Trader Workstation (TWS) API
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637363#comment-14637363 ] Daniel Pocock commented on CAMEL-9001: -- I agree, that code can't be copied into the Camel repository. None of that code has been copied into the pull request, all interaction is through the API. TWS itself is not open source at all and if you look closely you will find some of the code is obfuscated. It opens a socket to listen for connections from the Camel JVM. People have to view it as a black box or treat it as they would any external service. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8992) EIPs with Expression - Allow to detail those in jmx friendly information
[
https://issues.apache.org/jira/browse/CAMEL-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8992.
Resolution: Fixed
Fix Version/s: (was: Future)
2.16.0
> EIPs with Expression - Allow to detail those in jmx friendly information
>
>
> Key: CAMEL-8992
> URL: https://issues.apache.org/jira/browse/CAMEL-8992
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, jmx
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> The various EIPs have mbeans that exposes details about those processors.
> However when they use expression/predicate we only have the actual created
> instances of those available for JMX.
> That means they cannot reverse engineer or represent in a format that is
> better understood by humans/jmx/toolings.
> For example
> {code}
> from("direct:start")
> .pollEnrich().simple("seda:${header.whereto}").timeout(1000).id("mysend")
> .to("mock:foo");
> {code}
> The simple expression on poll enrich becomes
> {code}
> String uri = (String) mbeanServer.getAttribute(on, "Expression");
> assertEquals("Simple: seda:${header.whereto}", uri);
> {code}
> Ideally we should have two information
> - the language used for the expression
> - the value as-is
> So we can show that its simple language with the value
> "seda:${header.whereto}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8983) Add random function to simple
[
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637174#comment-14637174
]
Andrea Cosentino commented on CAMEL-8983:
-
Docs updated.
> Add random function to simple
> -
>
> Key: CAMEL-8983
> URL: https://issues.apache.org/jira/browse/CAMEL-8983
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.0
>
>
> We be nice with a random function in simple so you can do random delays
> during processor or whatnot
> {code}
> ${random(10)}
> {code}
> To return a random value between 0 and 9.
> And to do with range
> {code}
> ${random(10,20)}
> {code}
> To select a random number between 10 and 19.
> We may ponder a bit about the upper bound should be inclusive or exclusive?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8990) camel-guice - Upgrade to v4
[ https://issues.apache.org/jira/browse/CAMEL-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637146#comment-14637146 ] Andrea Cosentino commented on CAMEL-8990: - Everything is ok, we just need the bundle. I'll commit whenever it will be available. > camel-guice - Upgrade to v4 > --- > > Key: CAMEL-8990 > URL: https://issues.apache.org/jira/browse/CAMEL-8990 > Project: Camel > Issue Type: Improvement > Components: camel-guice >Reporter: Claus Ibsen >Assignee: Andrea Cosentino > Fix For: Future > > > There is a v4 released. We should upgrade. Not so how much pain there is > doing so, but if its not to hard, it would be good to get this done for the > next release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8990) camel-guice - Upgrade to v4
[ https://issues.apache.org/jira/browse/CAMEL-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-8990: External issue URL: https://issues.apache.org/jira/browse/SM-2626 External issue ID: SM-2626 > camel-guice - Upgrade to v4 > --- > > Key: CAMEL-8990 > URL: https://issues.apache.org/jira/browse/CAMEL-8990 > Project: Camel > Issue Type: Improvement > Components: camel-guice >Reporter: Claus Ibsen >Assignee: Andrea Cosentino > Fix For: Future > > > There is a v4 released. We should upgrade. Not so how much pain there is > doing so, but if its not to hard, it would be good to get this done for the > next release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7936) Add support for Query Params in the REST DSL
[ https://issues.apache.org/jira/browse/CAMEL-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637065#comment-14637065 ] Benjamin Habegger commented on CAMEL-7936: -- This feature doesn't seem to be documented. Any plans to have it documented ? How can we specify the query parameters ? > Add support for Query Params in the REST DSL > > > Key: CAMEL-7936 > URL: https://issues.apache.org/jira/browse/CAMEL-7936 > Project: Camel > Issue Type: New Feature > Components: camel-core, camel-swagger >Affects Versions: 2.14.0 >Reporter: Espen Tjonneland >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > Query parameters are currently supported implicitly through HTTP Headers. > However, this does not play very well with the new Swagger component. > Without the declarative support of query params in the Rest DSL camel-swagger > cannot add that information to the REST-description (api-docs). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8978) Setting of SOAP headers via the Camel Header "org.apache.cxf.headers.Header.list" not working for CXF data format "PAYLOAD"
[ https://issues.apache.org/jira/browse/CAMEL-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636939#comment-14636939 ] Franz Forsthofer commented on CAMEL-8978: - I updated also the wiki. > Setting of SOAP headers via the Camel Header > "org.apache.cxf.headers.Header.list" not working for CXF data format > "PAYLOAD" > > > Key: CAMEL-8978 > URL: https://issues.apache.org/jira/browse/CAMEL-8978 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.14.3, 2.15.2 >Reporter: Franz Forsthofer > Fix For: 2.16 > > Attachments: > 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch > > > In the camel-cxf documentation https://camel.apache.org/cxf.html is described > in the chapter "How to deal with the message for a camel-cxf endpoint in > PAYLOAD data format" that "You can use the Header.HEADER_LIST as the key to > set or get the SOAP headers". > But this only works for getting SOAP headers. > If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the > headers are not taken into account in the CXF-to-endpoint. > I analysed the problem and found out that > - the SOAP header list is forwarded to the CXF request context > - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by > the CxfPayload.getHeaders() value. > My suggestion is that we merge the headers from the Camel header and the the > CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. > With the merging we cover all different use cases: > - the headers can be set in the CxfPayload > - the headers can be set in the Camel header Header.list > - the headers can be set in the CXFPayload and the CamelHeader Header.list. > Also the case where the list instance in the CxfPayload is the same as in the > Camel header (in this case no merge is necessary) is covered. This case > happens if the from-endpoint is also a CXF endpoint and the CXF payload is > forwarded to the to-CXF-endpoint. > I can commit the change. However, before I do it I want to have the agreement > from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8978) Setting of SOAP headers via the Camel Header "org.apache.cxf.headers.Header.list" not working for CXF data format "PAYLOAD"
[ https://issues.apache.org/jira/browse/CAMEL-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-8978. - Resolution: Fixed Fix Version/s: (was: 2.14.4) (was: 2.15.3) I have fixed the issue only in 2.16 because there is another way described in the documentation: You can use CxfPayload.getHeaders() to set SOAP headers in the payload list. Nevertheless, with this improvement you can now also use the Camel Header. > Setting of SOAP headers via the Camel Header > "org.apache.cxf.headers.Header.list" not working for CXF data format > "PAYLOAD" > > > Key: CAMEL-8978 > URL: https://issues.apache.org/jira/browse/CAMEL-8978 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.14.3, 2.15.2 >Reporter: Franz Forsthofer > Fix For: 2.16 > > Attachments: > 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch > > > In the camel-cxf documentation https://camel.apache.org/cxf.html is described > in the chapter "How to deal with the message for a camel-cxf endpoint in > PAYLOAD data format" that "You can use the Header.HEADER_LIST as the key to > set or get the SOAP headers". > But this only works for getting SOAP headers. > If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the > headers are not taken into account in the CXF-to-endpoint. > I analysed the problem and found out that > - the SOAP header list is forwarded to the CXF request context > - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by > the CxfPayload.getHeaders() value. > My suggestion is that we merge the headers from the Camel header and the the > CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. > With the merging we cover all different use cases: > - the headers can be set in the CxfPayload > - the headers can be set in the Camel header Header.list > - the headers can be set in the CXFPayload and the CamelHeader Header.list. > Also the case where the list instance in the CxfPayload is the same as in the > Camel header (in this case no merge is necessary) is covered. This case > happens if the from-endpoint is also a CXF endpoint and the CXF payload is > forwarded to the to-CXF-endpoint. > I can commit the change. However, before I do it I want to have the agreement > from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8971) HazelcastAggregatorRepository redelivers incorrectly
[
https://issues.apache.org/jira/browse/CAMEL-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636915#comment-14636915
]
Ben O'Day commented on CAMEL-8971:
--
[~alexlomov] - not sure I follow how this disables recovery, can you clarify?
either way, this very basic unit test using the Hazelcast repo fails w/o my (or
some other) changes...any thoughts on how to address the root cause of the
issue otherwise?
> HazelcastAggregatorRepository redelivers incorrectly
>
>
> Key: CAMEL-8971
> URL: https://issues.apache.org/jira/browse/CAMEL-8971
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
>Affects Versions: 2.16
>Reporter: Ben O'Day
>Assignee: Ben O'Day
>Priority: Minor
> Attachments: HazelcastAggRepo-redelivery-fix.patch
>
>
> seeing an incorrect redelivery of a message when using the
> UseLatestAggregationStrategy...
> this very basic route (see attached)...
> from("direct:start")
> .aggregate(constant(true), new
> UseLatestAggregationStrategy())
> .completionSize(2)
>
> .aggregationRepository(repo)
> .to("mock:mock");
> resulting in a duplicate message being processed through the aggregator
> route...
> if the default in-memory repo is used, the test behaves as expected...no
> unnecessary redelivery, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636890#comment-14636890 ] ASF GitHub Bot commented on CAMEL-9001: --- GitHub user dpocock opened a pull request: https://github.com/apache/camel/pull/568 Ib api JIRA issue: https://issues.apache.org/jira/browse/CAMEL-9001 You can merge this pull request into a Git repository by running: $ git pull https://github.com/dpocock/camel ib-api Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/568.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 #568 commit 4625b603eddd3514dc9da71e6e0870cc0cf0c23b Author: Daniel Pocock Date: 2015-07-22T13:10:56Z CAMEL-9001: add camel-interactivebrokers component for TWS API commit 1a535568bb97dbb46babb9efd357ce1f4eb911cd Author: Daniel Pocock Date: 2015-07-22T13:14:37Z Merge branch 'master' into ib-api Conflicts: parent/pom.xml > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9001) add TWS component
[ https://issues.apache.org/jira/browse/CAMEL-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636889#comment-14636889 ] Daniel Pocock commented on CAMEL-9001: -- There is a demo app exercising each type of consumer and producer at https://github.com/OpenSourceTrading/tws-camel-demo I'll create a wiki page about the component once it has been merged. > add TWS component > - > > Key: CAMEL-9001 > URL: https://issues.apache.org/jira/browse/CAMEL-9001 > Project: Camel > Issue Type: New Feature >Affects Versions: 2.16.0 > Environment: all >Reporter: Daniel Pocock > Labels: features > > Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9001) add TWS component
Daniel Pocock created CAMEL-9001: Summary: add TWS component Key: CAMEL-9001 URL: https://issues.apache.org/jira/browse/CAMEL-9001 Project: Camel Issue Type: New Feature Affects Versions: 2.16.0 Environment: all Reporter: Daniel Pocock Add a component for the Interactive Brokers Trader Workstation (TWS) API -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9000) More friendly names for consumer and producer mbean names
[ https://issues.apache.org/jira/browse/CAMEL-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9000: --- Fix Version/s: (was: 2.16.0) Future 3.0.0 > More friendly names for consumer and producer mbean names > - > > Key: CAMEL-9000 > URL: https://issues.apache.org/jira/browse/CAMEL-9000 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 3.0.0, Future > > > They use identity hashcode as part of mbean name to make sure they are > unique. But if they are part of routes, we can use the route id, node id, as > they are unique, and its more understandable by end users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9000) More friendly names for consumer and producer mbean names
[ https://issues.apache.org/jira/browse/CAMEL-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636884#comment-14636884 ] Claus Ibsen commented on CAMEL-9000: As you can have potential 2+ consumers with the same uri, but for different routes, we could have a naming clash if we use uri as part of name for consumer. > More friendly names for consumer and producer mbean names > - > > Key: CAMEL-9000 > URL: https://issues.apache.org/jira/browse/CAMEL-9000 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > They use identity hashcode as part of mbean name to make sure they are > unique. But if they are part of routes, we can use the route id, node id, as > they are unique, and its more understandable by end users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8979) Camel Kafka component is using Producer and KeyedMessage class
[ https://issues.apache.org/jira/browse/CAMEL-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636585#comment-14636585 ] Anbumani Balusamy edited comment on CAMEL-8979 at 7/22/15 12:58 PM: Hi Claus, I am working on this patch and we can this code only for new Project as we have lot of changes in new Producer config. For example in older version we have Producer config property name partitioner.class and we have variable name partitioner in KafkaConfiguration to hold the options value. But in new version the property name partitioner.class is completely removed and we need to remove it from KafkaConfiguration class too. If the existing application use this patch code (Simply upgrading the jar) then it might break the flow as they might be passing the options partitioner.class (ie..kafka:// ? partitioner.class) but no variable to hold this value in KafkaConfiguration class was (Author: anbumani.balusamy): Hi Claus, I am working on this patch and we can this code only for new Project as we have lot of changes in Producer config. For example in older version we have Producer config property name partitioner.class and we have variable name partitioner in KafkaConfiguration to hold the options value. But in new version the property name partitioner.class is completely removed and we need to remove it from KafkaConfiguration class too. If the existing application use this patch code (Simply upgrading the jar) then it might break the flow as they might be passing the options partitioner.class (ie..kafka:// ? partitioner.class) but no variable to hold this value in KafkaConfiguration class > Camel Kafka component is using Producer and KeyedMessage class > -- > > Key: CAMEL-8979 > URL: https://issues.apache.org/jira/browse/CAMEL-8979 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Anbumani Balusamy >Priority: Minor > > Hi, I looked into the camel-kafka component version 2.15.2 and it's using old > Producer and KeyedMessage class for posting the message to kafka topic. From > 0.8.2 version we have new KafkaProducer and ProduceRecord classes. Can we > change the component to use the KafkaProducer and ProduceRecord classes? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8979) Camel Kafka component is using Producer and KeyedMessage class
[ https://issues.apache.org/jira/browse/CAMEL-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636869#comment-14636869 ] Anbumani Balusamy commented on CAMEL-8979: -- Here's the link to new Kafka Producer Config http://kafka.apache.org/documentation.html#newproducerconfigs > Camel Kafka component is using Producer and KeyedMessage class > -- > > Key: CAMEL-8979 > URL: https://issues.apache.org/jira/browse/CAMEL-8979 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Anbumani Balusamy >Priority: Minor > > Hi, I looked into the camel-kafka component version 2.15.2 and it's using old > Producer and KeyedMessage class for posting the message to kafka topic. From > 0.8.2 version we have new KafkaProducer and ProduceRecord classes. Can we > change the component to use the KafkaProducer and ProduceRecord classes? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9000) More friendly names for consumer and producer mbean names
[ https://issues.apache.org/jira/browse/CAMEL-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636827#comment-14636827 ] Claus Ibsen commented on CAMEL-9000: This may require that the route id and node id are applicable as part of mbean naming. eg if they have space and other symbols it may be a little problem. > More friendly names for consumer and producer mbean names > - > > Key: CAMEL-9000 > URL: https://issues.apache.org/jira/browse/CAMEL-9000 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > They use identity hashcode as part of mbean name to make sure they are > unique. But if they are part of routes, we can use the route id, node id, as > they are unique, and its more understandable by end users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9000) More friendly names for consumer and producer mbean names
Claus Ibsen created CAMEL-9000: -- Summary: More friendly names for consumer and producer mbean names Key: CAMEL-9000 URL: https://issues.apache.org/jira/browse/CAMEL-9000 Project: Camel Issue Type: Improvement Components: camel-core, jmx Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.16.0 They use identity hashcode as part of mbean name to make sure they are unique. But if they are part of routes, we can use the route id, node id, as they are unique, and its more understandable by end users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8992) EIPs with Expression - Allow to detail those in jmx friendly information
[
https://issues.apache.org/jira/browse/CAMEL-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-8992:
--
Assignee: Claus Ibsen
> EIPs with Expression - Allow to detail those in jmx friendly information
>
>
> Key: CAMEL-8992
> URL: https://issues.apache.org/jira/browse/CAMEL-8992
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, jmx
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: Future
>
>
> The various EIPs have mbeans that exposes details about those processors.
> However when they use expression/predicate we only have the actual created
> instances of those available for JMX.
> That means they cannot reverse engineer or represent in a format that is
> better understood by humans/jmx/toolings.
> For example
> {code}
> from("direct:start")
> .pollEnrich().simple("seda:${header.whereto}").timeout(1000).id("mysend")
> .to("mock:foo");
> {code}
> The simple expression on poll enrich becomes
> {code}
> String uri = (String) mbeanServer.getAttribute(on, "Expression");
> assertEquals("Simple: seda:${header.whereto}", uri);
> {code}
> Ideally we should have two information
> - the language used for the expression
> - the value as-is
> So we can show that its simple language with the value
> "seda:${header.whereto}"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8999) Watchdog route policy for spotting starved, overactive or stuck routes
[ https://issues.apache.org/jira/browse/CAMEL-8999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636790#comment-14636790 ] ASF GitHub Bot commented on CAMEL-8999: --- GitHub user yuruki opened a pull request: https://github.com/apache/camel/pull/567 CAMEL-8999 Watchdog route policy Watchdog route policy for spotting starved, overactive or stuck routes. You can merge this pull request into a Git repository by running: $ git pull https://github.com/yuruki/camel camel-watchdog Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/567.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 #567 commit 95f5f49289cb29e46c185a017541fa40f1d08a1c Author: Jyrki Ruuskanen Date: 2015-07-22T12:11:04Z Added WatchdogRoutePolicy > Watchdog route policy for spotting starved, overactive or stuck routes > -- > > Key: CAMEL-8999 > URL: https://issues.apache.org/jira/browse/CAMEL-8999 > Project: Camel > Issue Type: New Feature >Reporter: Jyrki Ruuskanen >Priority: Minor > > In our use case we need to spot routes that are processing less than expected > or too many exchanges in a certain time. The limits also depend on whether it > is a busy or a quiet time (day vs night, weekdays vs weekend etc.). > Also, we would like to be able to spot routes that are stuck but produce no > errors. > In my opinion the most natural solution is a RoutePolicy that would keep > count of inflight and completed exchanges and perform periodic checks on this > information. Multiple checks with different schedules would be allowed per > RoutePolicy instance. > If a check fails the RoutePolicy would log a warning. These warnings could > then be singled out based on the logger by, for example, an automated log > watcher. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8999) Watchdog route policy for spotting starved, overactive or stuck routes
Jyrki Ruuskanen created CAMEL-8999: -- Summary: Watchdog route policy for spotting starved, overactive or stuck routes Key: CAMEL-8999 URL: https://issues.apache.org/jira/browse/CAMEL-8999 Project: Camel Issue Type: New Feature Reporter: Jyrki Ruuskanen Priority: Minor In our use case we need to spot routes that are processing less than expected or too many exchanges in a certain time. The limits also depend on whether it is a busy or a quiet time (day vs night, weekdays vs weekend etc.). Also, we would like to be able to spot routes that are stuck but produce no errors. In my opinion the most natural solution is a RoutePolicy that would keep count of inflight and completed exchanges and perform periodic checks on this information. Multiple checks with different schedules would be allowed per RoutePolicy instance. If a check fails the RoutePolicy would log a warning. These warnings could then be singled out based on the logger by, for example, an automated log watcher. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8998) Camel-Git: add documetation to site
[ https://issues.apache.org/jira/browse/CAMEL-8998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-8998: --- Assignee: Andrea Cosentino > Camel-Git: add documetation to site > --- > > Key: CAMEL-8998 > URL: https://issues.apache.org/jira/browse/CAMEL-8998 > Project: Camel > Issue Type: Task > Components: documentation >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino > Fix For: 2.16.0 > > > We need to add Camel-git documentation to Camel site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8998) Camel-Git: add documetation to site
Andrea Cosentino created CAMEL-8998: --- Summary: Camel-Git: add documetation to site Key: CAMEL-8998 URL: https://issues.apache.org/jira/browse/CAMEL-8998 Project: Camel Issue Type: Task Components: documentation Reporter: Andrea Cosentino Fix For: 2.16.0 We need to add Camel-git documentation to Camel site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8997) Camel-Git: Add a show branches operation
Andrea Cosentino created CAMEL-8997: --- Summary: Camel-Git: Add a show branches operation Key: CAMEL-8997 URL: https://issues.apache.org/jira/browse/CAMEL-8997 Project: Camel Issue Type: New Feature Reporter: Andrea Cosentino Priority: Minor Fix For: 2.16.0 Adding a "show branches" operation to Camel-git producer can be useful in some situations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8997) Camel-Git: Add a show branches operation
[ https://issues.apache.org/jira/browse/CAMEL-8997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-8997: --- Assignee: Andrea Cosentino > Camel-Git: Add a show branches operation > > > Key: CAMEL-8997 > URL: https://issues.apache.org/jira/browse/CAMEL-8997 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 2.16.0 > > > Adding a "show branches" operation to Camel-git producer can be useful in > some situations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8996) Add support for Exchange.HTTP_QUERY
[
https://issues.apache.org/jira/browse/CAMEL-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636715#comment-14636715
]
Claus Ibsen commented on CAMEL-8996:
We should let it reuse camel-http so it can reuse that logic. And even better
if we get a camel-htttp-core module for better reuse
> Add support for Exchange.HTTP_QUERY
> ---
>
> Key: CAMEL-8996
> URL: https://issues.apache.org/jira/browse/CAMEL-8996
> Project: Camel
> Issue Type: New Feature
> Components: camel-undertow
>Reporter: Thomas Diesler
>
> Component camel-undertow
> Add support for
> {code}
> ProducerTemplate producer = camelctx.createProducerTemplate();
> String result = producer.requestBodyAndHeader("direct:start",
> null, Exchange.HTTP_QUERY, "name=Kermit", String.class);
> Assert.assertEquals("Hello Kermit", result);
> {code}
> and possibly other headers. This works for camel-http4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8996) Add support for Exchange.HTTP_QUERY
[
https://issues.apache.org/jira/browse/CAMEL-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8996:
---
Component/s: camel-undertow
> Add support for Exchange.HTTP_QUERY
> ---
>
> Key: CAMEL-8996
> URL: https://issues.apache.org/jira/browse/CAMEL-8996
> Project: Camel
> Issue Type: New Feature
> Components: camel-undertow
>Reporter: Thomas Diesler
>
> Component camel-undertow
> Add support for
> {code}
> ProducerTemplate producer = camelctx.createProducerTemplate();
> String result = producer.requestBodyAndHeader("direct:start",
> null, Exchange.HTTP_QUERY, "name=Kermit", String.class);
> Assert.assertEquals("Hello Kermit", result);
> {code}
> and possibly other headers. This works for camel-http4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8996) Add support for Exchange.HTTP_QUERY
Thomas Diesler created CAMEL-8996:
-
Summary: Add support for Exchange.HTTP_QUERY
Key: CAMEL-8996
URL: https://issues.apache.org/jira/browse/CAMEL-8996
Project: Camel
Issue Type: New Feature
Reporter: Thomas Diesler
Component camel-undertow
Add support for
{code}
ProducerTemplate producer = camelctx.createProducerTemplate();
String result = producer.requestBodyAndHeader("direct:start", null,
Exchange.HTTP_QUERY, "name=Kermit", String.class);
Assert.assertEquals("Hello Kermit", result);
{code}
and possibly other headers. This works for camel-http4
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-2983) RestEasy component
[
https://issues.apache.org/jira/browse/CAMEL-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636613#comment-14636613
]
Roman jakubco commented on CAMEL-2983:
--
I am currently working on pull request to master branch of Camel, but I have
few issues with tests because of Arquillian that is used in them. I am using
ShrinkWrap for creation of war file used for testing and ShrinkWrap uses
Maven.resolver for resolving dependencies from pom.xml which are required for
bundle that is deployed into the wildfly.
I spent whole yesterday looking for cause of the problem and I think it is
because of [1] file is imported into the maven when build is executed and this
property {{@localRepositoryUrl@}} is the main problem for
Maven.resolver in ShrinkWrap. I need to find a way to bypass this or rewrite
tests so that they are executable in Camel repo. So I will try to do this as
soon as possible.
[1]
https://github.com/romanjakubco/camel/blob/camel-resteasy/tooling/maven/camel-api-component-maven-plugin/src/it/settings.xml
> RestEasy component
> --
>
> Key: CAMEL-2983
> URL: https://issues.apache.org/jira/browse/CAMEL-2983
> Project: Camel
> Issue Type: New Feature
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> Consider JBoss RestEasy 2.x which has been released under ASL 2.0 license now.
> http://jboss.org/resteasy
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8979) Camel Kafka component is using Producer and KeyedMessage class
[ https://issues.apache.org/jira/browse/CAMEL-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636585#comment-14636585 ] Anbumani Balusamy commented on CAMEL-8979: -- Hi Claus, I am working on this patch and we can this code only for new Project as we have lot of changes in Producer config. For example in older version we have Producer config property name partitioner.class and we have variable name partitioner in KafkaConfiguration to hold the options value. But in new version the property name partitioner.class is completely removed and we need to remove it from KafkaConfiguration class too. If the existing application use this patch code (Simply upgrading the jar) then it might break the flow as they might be passing the options partitioner.class (ie..kafka:// ? partitioner.class) but no variable to hold this value in KafkaConfiguration class > Camel Kafka component is using Producer and KeyedMessage class > -- > > Key: CAMEL-8979 > URL: https://issues.apache.org/jira/browse/CAMEL-8979 > Project: Camel > Issue Type: Improvement > Components: camel-kafka >Reporter: Anbumani Balusamy >Priority: Minor > > Hi, I looked into the camel-kafka component version 2.15.2 and it's using old > Producer and KeyedMessage class for posting the message to kafka topic. From > 0.8.2 version we have new KafkaProducer and ProduceRecord classes. Can we > change the component to use the KafkaProducer and ProduceRecord classes? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-2983) RestEasy component
[ https://issues.apache.org/jira/browse/CAMEL-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636583#comment-14636583 ] Gareth Healy commented on CAMEL-2983: - Has anything happened with this? I can't see the camel-resteasy doc page, so i presume not. But the github repo is still active. > RestEasy component > -- > > Key: CAMEL-2983 > URL: https://issues.apache.org/jira/browse/CAMEL-2983 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen > Fix For: Future > > > Consider JBoss RestEasy 2.x which has been released under ASL 2.0 license now. > http://jboss.org/resteasy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8973) Add Batching JMS component
[
https://issues.apache.org/jira/browse/CAMEL-8973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-8973.
Resolution: Fixed
Assignee: Claus Ibsen
Thanks
> Add Batching JMS component
> --
>
> Key: CAMEL-8973
> URL: https://issues.apache.org/jira/browse/CAMEL-8973
> Project: Camel
> Issue Type: New Feature
> Components: camel-sjms
>Reporter: Jakub Korab
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> Add specialised component that performs batch consumption of messages from a
> JMS destination using local transactions.
> Pull request to follow.
> Original post to mailing list:
> --
> I have written a consumer-only component that combines aggregation logic
> with transacted JMS sessions that I would like to contribute. The
> component
> vastly speeds up message consumption and aggregation without message loss
> on failure when compared with using a regular JMS component and
> aggregator.
> The problem that it solves is that when you want to aggregate a set of
> messages from JMS and avoid message loss, you typically reach for a
> JdbcAggregationRepository. This in turn fetches and writes progressively
> larger blobs from the database on receipt of each message, slowing down
> linearly in relation to to the number of messages consumed - i.e. it
> performs progressively worse the larger the batch.
> Old way:
> from("jms:myQueue")
> .transacted()
> .aggregate(constant(true), myAggStrategy)
> .aggregationRepository(jdbcAggregationRepository)
> .completionSize(100)
> .completionTimeout(500)
> This also suffers from a problem that message loss is still possible
> between the message broker and the database that stores the aggregated
> message (unless you use XA transactions).
> The component that I have developed starts a JMS session, and receives
> messages synchronously until it meets a completion size, or until a
> completion timeout is met, each time calling an AggregationStrategy. Only
> when the completion conditions have been matched does it emit the
> aggregated message.
> The component will commit the batch transaction if the Exchange is
> processed successfully, or roll the entire thing back on exception - so
> all of the original messages will end up back on the queue for re-processing.
> In the event of failure of the Camel process, the messages remain on the
> broker for re-dispatch.
> So in terms of "where is my data stored?", the answer is it remains on
> thebroker until the batch is successfully processed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8994. Resolution: Implemented Assignee: Claus Ibsen > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.3, 2.14.4 > > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636473#comment-14636473 ] Claus Ibsen edited comment on CAMEL-8994 at 7/22/15 8:08 AM: - The initial size has been dropped to 16 - for the other you will have to wait for when we drop Java7 was (Author: davsclaus): The initial size has been dropped to 16 - for the other you will have to wait for when we drop Java8 > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > Fix For: 2.16.0, 2.15.3, 2.14.4 > > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636473#comment-14636473 ] Claus Ibsen commented on CAMEL-8994: The initial size has been dropped to 16 - for the other you will have to wait for when we drop Java8 > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > Fix For: 2.16.0, 2.15.3, 2.14.4 > > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8994: --- Fix Version/s: 2.14.4 > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > Fix For: 2.16.0, 2.15.3, 2.14.4 > > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8994: --- Fix Version/s: 2.15.3 2.16.0 > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > Fix For: 2.16.0, 2.15.3 > > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636461#comment-14636461 ] Claus Ibsen commented on CAMEL-8994: There is a ticket about upgrading the CL HashMap but that newer version is Java8+ only. And Camel supports Java7. > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636463#comment-14636463 ] Claus Ibsen commented on CAMEL-8994: Yeah good idea to adjust the iniitalize size, its own default is 16, which we will do also. > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8994) Large memory use on Large core count(512) servers
[ https://issues.apache.org/jira/browse/CAMEL-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8994: --- Issue Type: Improvement (was: Bug) > Large memory use on Large core count(512) servers > - > > Key: CAMEL-8994 > URL: https://issues.apache.org/jira/browse/CAMEL-8994 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 >Reporter: Zoltan Farkas > > ConcurrentLinkedHashmap get huge on these servers (200 +Mb) > There are some CPU related defaults + Some padding that are the source of > this, more discussion at: > https://github.com/ben-manes/concurrentlinkedhashmap/issues/43 > upgrading to a newer version should remove the padding and reduce memory > usage... > Another thing I noticed that is related, is that LRUCache > default initial size is equal with maximum size... which is 1000, would it > make more sense to have a lower default for initialSize? (64) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8990) camel-guice - Upgrade to v4
[ https://issues.apache.org/jira/browse/CAMEL-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636403#comment-14636403 ] Andrea Cosentino commented on CAMEL-8990: - It seems there is no problem. We also need the 4.0 bundle. I'll open a ticket to SM guys. > camel-guice - Upgrade to v4 > --- > > Key: CAMEL-8990 > URL: https://issues.apache.org/jira/browse/CAMEL-8990 > Project: Camel > Issue Type: Improvement > Components: camel-guice >Reporter: Claus Ibsen >Assignee: Andrea Cosentino > Fix For: Future > > > There is a v4 released. We should upgrade. Not so how much pain there is > doing so, but if its not to hard, it would be good to get this done for the > next release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8983) Add random function to simple
[
https://issues.apache.org/jira/browse/CAMEL-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636404#comment-14636404
]
Andrea Cosentino commented on CAMEL-8983:
-
Yeah, for sure.
> Add random function to simple
> -
>
> Key: CAMEL-8983
> URL: https://issues.apache.org/jira/browse/CAMEL-8983
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.16.0
>
>
> We be nice with a random function in simple so you can do random delays
> during processor or whatnot
> {code}
> ${random(10)}
> {code}
> To return a random value between 0 and 9.
> And to do with range
> {code}
> ${random(10,20)}
> {code}
> To select a random number between 10 and 19.
> We may ponder a bit about the upper bound should be inclusive or exclusive?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-8990) camel-guice - Upgrade to v4
[ https://issues.apache.org/jira/browse/CAMEL-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reassigned CAMEL-8990: --- Assignee: Andrea Cosentino > camel-guice - Upgrade to v4 > --- > > Key: CAMEL-8990 > URL: https://issues.apache.org/jira/browse/CAMEL-8990 > Project: Camel > Issue Type: Improvement > Components: camel-guice >Reporter: Claus Ibsen >Assignee: Andrea Cosentino > Fix For: Future > > > There is a v4 released. We should upgrade. Not so how much pain there is > doing so, but if its not to hard, it would be good to get this done for the > next release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
