[jira] [Commented] (CAMEL-10502) Camel-git : Copy headers from in to out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684842#comment-15684842
 ] 

ASF GitHub Bot commented on CAMEL-10502:


GitHub user chenapan opened a pull request:

https://github.com/apache/camel/pull/1291

CAMEL-10502 - Camel-git : Copy headers from in to out

Preferred working on separate branches instead of master as it moves a lot. 
Sorry for that. You can accept PRs the order you want, I'll fix the conflicts 
as soon as master changes...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chenapan/camel CAMEL-10502

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1291.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 #1291


commit 8ab374b1ea3074d64bbde4cfca25a6751572f622
Author: Olivier Antibi 
Date:   2016-11-21T17:09:36Z

CAMEL-10502 - Camel-git : Copy headers from in to out




> Camel-git : Copy headers from in to out
> ---
>
> Key: CAMEL-10502
> URL: https://issues.apache.org/jira/browse/CAMEL-10502
> Project: Camel
>  Issue Type: Task
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
> Fix For: 2.19.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Camel-git has been thought to be used as different separate commands, so a 
> new message is built after each git commands(use of exchange.getOut()). If 
> you try to chain 2 different commands (add and commit), you will loose the 
> camel headers in between.
> The idea is to copy headers from in to out. Another solution could be to 
> modify "exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10502) Camel-git : Copy headers from in to out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684825#comment-15684825
 ] 

ASF GitHub Bot commented on CAMEL-10502:


Github user chenapan closed the pull request at:

https://github.com/apache/camel/pull/1287


> Camel-git : Copy headers from in to out
> ---
>
> Key: CAMEL-10502
> URL: https://issues.apache.org/jira/browse/CAMEL-10502
> Project: Camel
>  Issue Type: Task
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
> Fix For: 2.19.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Camel-git has been thought to be used as different separate commands, so a 
> new message is built after each git commands(use of exchange.getOut()). If 
> you try to chain 2 different commands (add and commit), you will loose the 
> camel headers in between.
> The idea is to copy headers from in to out. Another solution could be to 
> modify "exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684312#comment-15684312
 ] 

Sverker Abrahamsson commented on CAMEL-10391:
-

Yes, the event variant would be beautiful. Didn't think of that it would be 
possible to change parameters in the event object.

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Antonin Stefanutti (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684290#comment-15684290
 ] 

Antonin Stefanutti commented on CAMEL-10391:


{quote}
How do you do optional injects in other way than using Optional?
{quote}
it is possible to do optional programmatic lookup with {{Instance}} or the 
{{BeanManager}}.

{quote}
CdiCamelExtension isn't serializable neither so that part shouldn't be a 
problem. Top pom in camel still defines jdk version to 1.7.
{quote}
See:  
https://github.com/apache/camel/blob/da8694f8c5392881ac5ab49c37a7947451bb65af/pom.xml#L49

{quote}
How would the event variant work?
{quote}
I'm thinking about what is done in the Metrics CDI extension: 
https://github.com/astefanutti/metrics-cdi/blob/abac97f7d903651884de92421ce53bf7d0499d08/impl/src/main/java/io/astefanutti/metrics/cdi/MetricsConfigurationEvent.java#L23

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684276#comment-15684276
 ] 

Sverker Abrahamsson commented on CAMEL-10391:
-

How do you do optional injects in other way than using Optional? 
CdiCamelExtension isn't serializable neither so that part shouldn't be a 
problem. Top pom in camel still defines jdk version to 1.7.

Agreed that an interface is better for type safety. How would the event variant 
work?

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Antonin Stefanutti (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684247#comment-15684247
 ] 

Antonin Stefanutti commented on CAMEL-10391:


Camel CDI compiles on Java 8 since Camel 2.18.0 so that would be fine.  Though 
having {{Optional}} members in always debatable as it is not serialisable. 
Indeed it has been designed to be used more as return type than to carry state. 
See [Optional Injection Points|https://issues.jboss.org/browse/CDI-45] for some 
elements on this.

For the configuration API, I was thinking about an interface that the user 
could implement that's more type safe than a {{Properties}} bean. The extension 
can easily deal with optionality. Or an event fired by the extension providing 
a event object that the user could use to pass some configuration. the later 
would be more CDI-ish IMO.

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684199#comment-15684199
 ] 

Sverker Abrahamsson commented on CAMEL-10391:
-

I see now that Optional came in Java 8, and camel-cdi is compiled with source 
level 1.7 ..

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10502) Camel-git : Copy headers from in to out

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684193#comment-15684193
 ] 

ASF GitHub Bot commented on CAMEL-10502:


GitHub user chenapan opened a pull request:

https://github.com/apache/camel/pull/1287

CAMEL-10502 - Camel-git : Copy headers from in to out

I set up common methods (validateGitLogs, and updateExchange) that I used 
for my issue only, if fine with you I could refactor existing tests using them.

I suggest using utility functions in JGit to prepare git repository before 
calling camel-git features, we could then decouple the tests that uses 
camel-git and then assumes they work fine. 

Let me know if such a refactoring could be done.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chenapan/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1287.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 #1287






> Camel-git : Copy headers from in to out
> ---
>
> Key: CAMEL-10502
> URL: https://issues.apache.org/jira/browse/CAMEL-10502
> Project: Camel
>  Issue Type: Task
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
> Fix For: 2.19.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Camel-git has been thought to be used as different separate commands, so a 
> new message is built after each git commands(use of exchange.getOut()). If 
> you try to chain 2 different commands (add and commit), you will loose the 
> camel headers in between.
> The idea is to copy headers from in to out. Another solution could be to 
> modify "exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684140#comment-15684140
 ] 

Sverker Abrahamsson edited comment on CAMEL-10391 at 11/21/16 5:28 PM:
---

Any suggestion on how to start on a configuration API?

How about injecting an optional properties class in CdiCamelExtension?
{noformat}
@Inject @CdiCamelProperties
private Optional cdiCamelProperties;
{noformat}

With for this purpose a property autoStartRoutes.

Or a variant which implements an interface with usable properties:
{noformat}
@Inject
private Optional<@CdiCamelProperties> cdiCamelProperties;
{noformat}



was (Author: sverker):
Any suggestion on how to start on a configuration API?

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684140#comment-15684140
 ] 

Sverker Abrahamsson commented on CAMEL-10391:
-

Any suggestion on how to start on a configuration API?

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Antonin Stefanutti (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684131#comment-15684131
 ] 

Antonin Stefanutti commented on CAMEL-10391:


{quote}
Looking at this again. Isn't the obvious solution that only RouteBuilders 
annotated with @Startup should be automatically added to the context? Although 
that is an EJB annotation..
{quote}
I doubt adding an explicit dependency on the EJB specification would be wise.
{quote}
I know it breaks compatibility but that's how it should have been from 
beginning ..
{quote}
It has to be kept in mind that 95% of user feedback we've got is that they want 
to have their Camel context started with the container. Hence the convention to 
start the Camel CDI contexts for these vast majority of users. Still a proper 
configuration API has to be provided for the remaining users. 

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684074#comment-15684074
 ] 

Sverker Abrahamsson edited comment on CAMEL-10391 at 11/21/16 5:03 PM:
---

Looking at this again. Isn't the obvious solution that only RouteBuilders 
annotated with @Startup should be automatically added to the context? Although 
that is an EJB annotation.. I know it breaks compatibility but that's how it 
should have been from beginning ..

Any suggestion on how to implement a configuration bean as discussed above?


was (Author: sverker):
Looking at this again. Isn't the obvious solution that only RouteBuilders 
annotated with @Startup should be automatically added to the context? I know it 
breaks compatibility but that's how it should have been from beginning ..

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10391) Camel-CDI adds every RouteBuilder instance it can find to Camel context

[Sverker Abrahamsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684074#comment-15684074
 ] 

Sverker Abrahamsson commented on CAMEL-10391:
-

Looking at this again. Isn't the obvious solution that only RouteBuilders 
annotated with @Startup should be automatically added to the context? I know it 
breaks compatibility but that's how it should have been from beginning ..

> Camel-CDI adds every RouteBuilder instance it can find to Camel context
> ---
>
> Key: CAMEL-10391
> URL: https://issues.apache.org/jira/browse/CAMEL-10391
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.18.0
> Environment: Wildfly 10 with wildfly-camel extension
>Reporter: Sverker Abrahamsson
>Assignee: Antonin Stefanutti
>
> Camel-CDI will find every class in a deployment which extends RouteBuilder 
> and automatically add them to the context. This is a major issue for me as I 
> usually wants to instantiate my RouteBuilders programatically setting various 
> parameters, with CDI support.
> This behaviour was introduced with 
> https://github.com/apache/camel/commit/0421c24dfcf992f3296ed746469771e3800200e3
>  from [~antonin.stefanutti] and we had a good discussion about the issue on 
> his github project in https://github.com/astefanutti/camel-cdi/issues/12 but 
> never came up with a good solution for it. I have patched camel-cdi to use a 
> marker annotation @DoNotAddToCamelContext to work around it but I don't want 
> to have to patch every release I use..
> I understand the logic why Camel-CDI finds and add every RouteBuilder class, 
> even though I don't agree that it is a good idea but it could very well be 
> the default behavior as long as it is possible to override it.
> What I would like is a discussion on how this could be made configurable. I'm 
> thinking about if there could be an annotation like 
> @CamelContextStartup(false) or maybe even a more general 
> @CamelContextConfig(autostart=false) if there are other things that should be 
> configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10491) Spring-LDAP - Add support for authenticate, modify_attributes and function_driven operations

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684073#comment-15684073
 ] 

ASF GitHub Bot commented on CAMEL-10491:


GitHub user bhaveshdt opened a pull request:

https://github.com/apache/camel/pull/1286

CAMEL-10491 - Spring-LDAP - Updated documentation to reflect the new 
operations.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bhaveshdt/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1286.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 #1286


commit 2f26ffe96e085df7e2bb6f0a52d6a6e1d3852e6f
Author: Bhavesh Thakker 
Date:   2016-11-16T20:59:45Z

Added support for authenticate, modify_attributes and function_driven 
operations

commit bb73292c44dd916dba51304edceee0c1d16307aa
Author: THAKKBH 
Date:   2016-11-16T21:23:17Z

Check-style related changes

commit 1a4519f25036b415707a49cc020d1b3b99c7f0ae
Author: Bhavesh Thakker 
Date:   2016-11-16T21:23:17Z

Check-style related changes

commit 77e763aec6e21b5aee523db00ef70054157c9dc8
Author: Thakker 
Date:   2016-11-16T21:25:34Z

Merge branch 'master' of https://github.com/bhaveshdt/camel

commit ded7ebdb0ee5b8272d8d3107c217cb8555e818e8
Author: Thakker 
Date:   2016-11-17T14:52:10Z

Merge remote-tracking branch 'camel_upstream/master'

commit dd4546c905607930213826be5328385ca51998c6
Author: Thakker 
Date:   2016-11-21T16:03:01Z

CAMEL-10491 - Spring-LDAP - Updated component documentation

commit 4898e8575b576ea6b61dec846e4f109a030d581b
Author: Thakker 
Date:   2016-11-21T16:04:38Z

Merge remote-tracking branch 'camel_upstream/master'




> Spring-LDAP - Add support for authenticate, modify_attributes and 
> function_driven operations
> 
>
> Key: CAMEL-10491
> URL: https://issues.apache.org/jira/browse/CAMEL-10491
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 2.19.0
>Reporter: Bhavesh
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10491) Spring-LDAP - Add support for authenticate, modify_attributes and function_driven operations

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15684065#comment-15684065
 ] 

ASF GitHub Bot commented on CAMEL-10491:


Github user bhaveshdt closed the pull request at:

https://github.com/apache/camel/pull/1276


> Spring-LDAP - Add support for authenticate, modify_attributes and 
> function_driven operations
> 
>
> Key: CAMEL-10491
> URL: https://issues.apache.org/jira/browse/CAMEL-10491
> Project: Camel
>  Issue Type: Improvement
>Affects Versions: 2.19.0
>Reporter: Bhavesh
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.19.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10213) Camel Kafka doesn't support setting "max.poll.records" and "session.timeout.ms"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683926#comment-15683926
 ] 

ASF GitHub Bot commented on CAMEL-10213:


Github user landonvg closed the pull request at:

https://github.com/apache/camel/pull/1279


> Camel Kafka doesn't support setting "max.poll.records" and 
> "session.timeout.ms" 
> 
>
> Key: CAMEL-10213
> URL: https://issues.apache.org/jira/browse/CAMEL-10213
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-kafka
>Affects Versions: 2.18.0
>Reporter: Oliver Holzmann
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.0
>
>
> Currently it is not possible to control the processing time in the poll loop 
> in Camel Kafka consumers. 
> It is important to have the possibility to control the poll loop by adjusting 
> {{max.poll.records}} and {{session.timeout.ms}} . Otherwise this warning is 
> produced when consuming a large backlog from kafka topic:
> {code}
> Auto offset commit failed for group consumerGroup: Commit cannot be 
> completed since the group has already rebalanced and assigned the 
> partitions to another member. This means that the time between 
> subsequent calls to poll() was longer than the configured 
> session.timeout.ms, which typically implies that the poll loop is spending 
> too much time message processing. You can address this either by 
> increasing the session timeout or by reducing the maximum size of batches
> returned in poll() with max.poll.records.
> {code}
> Please add {{max.poll.records}} and {{session.timeout.ms}} to Kafka endpoint 
> configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (CAMEL-10492) Camel Servlet, attachment object is empty

[Fabrizio Spataro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Fabrizio Spataro reopened CAMEL-10492:
--

please, look at my last comment

> Camel Servlet, attachment object is empty
> -
>
> Key: CAMEL-10492
> URL: https://issues.apache.org/jira/browse/CAMEL-10492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common, camel-servlet
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Claus Ibsen
> Fix For: 2.18.1, 2.19.0
>
> Attachments: camel-example-servlet-attachment.zip
>
>
> I send a multipart form data to my camel servlet, before camel 2.18 
> attachment object is ok now is empty!
> Now i have an *header* every form field but every field is java.lang.String
> So, I can not post any binary file.
> This is my web.xml filter
> {code:xml}
>   
>   MultipartFilter
>   
> org.eclipse.jetty.servlets.MultiPartFilter
>   
>   
>   MultipartFilter
>   CamelServlet
>   
> {code}
> Into zip file, you can found an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Evgenii Lomonosov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683740#comment-15683740
 ] 

Evgenii Lomonosov edited comment on CAMEL-10504 at 11/21/16 2:41 PM:
-

MongoDbBasicConverters.fromAnyObjectToDBObject(Object value) - this method logs 
a message that, in my opinion, should consist an information about underlying 
exception.


was (Author: elomonos):
MongoDbBasicConverters.fromAnyObjectToDBObject(Object value) - this method 
throws an exception that, in my opinion, should consist an information about 
underlying exception.

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3
>Reporter: Evgenii Lomonosov
>Priority: Minor
>  Labels: debug, troubleshooting
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Evgenii Lomonosov (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683740#comment-15683740
 ] 

Evgenii Lomonosov commented on CAMEL-10504:
---

MongoDbBasicConverters.fromAnyObjectToDBObject(Object value) - this method 
throws an exception that, in my opinion, should consist an information about 
underlying exception.

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3
>Reporter: Evgenii Lomonosov
>Priority: Minor
>  Labels: debug, troubleshooting
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683752#comment-15683752
 ] 

Andrea Cosentino commented on CAMEL-10504:
--

Can you make some tests with camel-2.18.0 too? Thanks. Just to understand if 
something has changed (I think the answer is no).

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: debug, troubleshooting
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Andrea Cosentino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10504:


Assignee: Andrea Cosentino

> Hiding an underlying exception if MongoDbBasicConverters fails to convert to 
> DBObject
> -
>
> Key: CAMEL-10504
> URL: https://issues.apache.org/jira/browse/CAMEL-10504
> Project: Camel
>  Issue Type: Bug
>  Components: camel-mongodb
>Affects Versions: 2.17.3
>Reporter: Evgenii Lomonosov
>Assignee: Andrea Cosentino
>Priority: Minor
>  Labels: debug, troubleshooting
>
> If conversion fails it could be hard to understand what is a problem because 
> it returns just a message "Conversion has fallen back to generic Object -> 
> DBObject, but unable to convert type {}. Returning null" that points to a 
> class that was not converted.
> In case of, as example, if a list of objects that should be converted leads 
> to a memory error because of parent-child link are cycled for 2 objects, it 
> would take a lot of efforts to understand what is going on. And information 
> about underlying exception, stackoverflow in this case, could help to find 
> the root cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10504) Hiding an underlying exception if MongoDbBasicConverters fails to convert to DBObject

[Evgenii Lomonosov (JIRA)]

Evgenii Lomonosov created CAMEL-10504:
-

 Summary: Hiding an underlying exception if MongoDbBasicConverters 
fails to convert to DBObject
 Key: CAMEL-10504
 URL: https://issues.apache.org/jira/browse/CAMEL-10504
 Project: Camel
  Issue Type: Bug
  Components: camel-mongodb
Affects Versions: 2.17.3
Reporter: Evgenii Lomonosov
Priority: Minor


If conversion fails it could be hard to understand what is a problem because it 
returns just a message "Conversion has fallen back to generic Object -> 
DBObject, but unable to convert type {}. Returning null" that points to a class 
that was not converted.

In case of, as example, if a list of objects that should be converted leads to 
a memory error because of parent-child link are cycled for 2 objects, it would 
take a lot of efforts to understand what is going on. And information about 
underlying exception, stackoverflow in this case, could help to find the root 
cause much faster than now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10503) Camel-Git: Add RemoteAdd command

[Andrea Cosentino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10503:


Assignee: Andrea Cosentino

> Camel-Git: Add RemoteAdd command
> 
>
> Key: CAMEL-10503
> URL: https://issues.apache.org/jira/browse/CAMEL-10503
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
> Fix For: 2.19.0
>
>
> Add command corresponding to native "git remote add", linked to 
> "GitRemoteAddCommand" in JGit.
> In case you initialise an empty repository (not using "git clone"), then this 
> RemoteAddCommand is needed to be able to push changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10503) Camel-Git: Add RemoteAdd command

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683646#comment-15683646
 ] 

Andrea Cosentino commented on CAMEL-10503:
--

+1, thanks for you work!

> Camel-Git: Add RemoteAdd command
> 
>
> Key: CAMEL-10503
> URL: https://issues.apache.org/jira/browse/CAMEL-10503
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
> Fix For: 2.19.0
>
>
> Add command corresponding to native "git remote add", linked to 
> "GitRemoteAddCommand" in JGit.
> In case you initialise an empty repository (not using "git clone"), then this 
> RemoteAddCommand is needed to be able to push changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10502) Camel-git : Copy headers from in to out

[Andrea Cosentino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10502:


Assignee: Andrea Cosentino

> Camel-git : Copy headers from in to out
> ---
>
> Key: CAMEL-10502
> URL: https://issues.apache.org/jira/browse/CAMEL-10502
> Project: Camel
>  Issue Type: Task
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
> Fix For: 2.19.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Camel-git has been thought to be used as different separate commands, so a 
> new message is built after each git commands(use of exchange.getOut()). If 
> you try to chain 2 different commands (add and commit), you will loose the 
> camel headers in between.
> The idea is to copy headers from in to out. Another solution could be to 
> modify "exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10502) Camel-git : Copy headers from in to out

[Andrea Cosentino (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683645#comment-15683645
 ] 

Andrea Cosentino commented on CAMEL-10502:
--

Good improvement. +1 for me. Thanks!

> Camel-git : Copy headers from in to out
> ---
>
> Key: CAMEL-10502
> URL: https://issues.apache.org/jira/browse/CAMEL-10502
> Project: Camel
>  Issue Type: Task
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
> Fix For: 2.19.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Camel-git has been thought to be used as different separate commands, so a 
> new message is built after each git commands(use of exchange.getOut()). If 
> you try to chain 2 different commands (add and commit), you will loose the 
> camel headers in between.
> The idea is to copy headers from in to out. Another solution could be to 
> modify "exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10503) Camel-Git: Add RemoteAdd command

[Olivier Antibi (JIRA)]

Olivier Antibi created CAMEL-10503:
--

 Summary: Camel-Git: Add RemoteAdd command
 Key: CAMEL-10503
 URL: https://issues.apache.org/jira/browse/CAMEL-10503
 Project: Camel
  Issue Type: Improvement
  Components: camel-git
Affects Versions: 2.18.0
Reporter: Olivier Antibi
 Fix For: 2.19.0


Add command corresponding to native "git remote add", linked to 
"GitRemoteAddCommand" in JGit.

In case you initialise an empty repository (not using "git clone"), then this 
RemoteAddCommand is needed to be able to push changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10502) Camel-git : Copy headers from in to out

[Olivier Antibi (JIRA)]

Olivier Antibi created CAMEL-10502:
--

 Summary: Camel-git : Copy headers from in to out
 Key: CAMEL-10502
 URL: https://issues.apache.org/jira/browse/CAMEL-10502
 Project: Camel
  Issue Type: Task
  Components: camel-git
Affects Versions: 2.18.0
Reporter: Olivier Antibi
 Fix For: 2.19.0


Camel-git has been thought to be used as different separate commands, so a new 
message is built after each git commands(use of exchange.getOut()). If you try 
to chain 2 different commands (add and commit), you will loose the camel 
headers in between.

The idea is to copy headers from in to out. Another solution could be to modify 
"exchange.getIn()" instead of using "exchange.getOut()".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10500) Camel-Git: Add allowEmpty commits option

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683575#comment-15683575
 ] 

ASF GitHub Bot commented on CAMEL-10500:


Github user chenapan closed the pull request at:

https://github.com/apache/camel/pull/1284


> Camel-Git: Add allowEmpty commits option 
> -
>
> Key: CAMEL-10500
> URL: https://issues.apache.org/jira/browse/CAMEL-10500
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
>Priority: Trivial
> Fix For: 2.19.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> By default, JGit behaves differently than native git allowing empty commits. 
> This first change is to add a new option to the GitEndpoint to be able to 
> turn that option to false. I let it default to "true" in a first move to have 
> backward compatibility but suggest we could default to "false" to match 
> native git behaviour (git commit --allow-empty)
> This will raise an exception for empty commits, may be a silent mode to log 
> warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10492) Camel Servlet, attachment object is empty

[Fabrizio Spataro (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683561#comment-15683561
 ] 

Fabrizio Spataro commented on CAMEL-10492:
--

[~davsclaus] This bug is more complex than it looks. When i set 
attachmentMultipartBinding property i have another error.

It isn't a jetty bug (i had test it with junit) but it, i suppose, is a camel 
body trasformation bug. I do not know so thoroughly to understand it. Can you 
help me?

You can use my zip attach file to debug it!

Stacktrace

{code}
org.apache.camel.RuntimeCamelException: Cannot populate attachments
at 
org.apache.camel.component.servlet.AttachmentHttpBinding.populateAttachments(AttachmentHttpBinding.java:58)
at 
org.apache.camel.http.common.DefaultHttpBinding.readBody(DefaultHttpBinding.java:209)
at 
org.apache.camel.http.common.DefaultHttpBinding.readRequest(DefaultHttpBinding.java:107)
at org.apache.camel.http.common.HttpMessage.(HttpMessage.java:52)
at 
org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:169)
at 
org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:74)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at 
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:830)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:551)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1589)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1213)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:486)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1552)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1126)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:118)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:549)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:254)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:269)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:97)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Missing content for multipart request
at 
org.eclipse.jetty.util.MultiPartInputStreamParser.parse(MultiPartInputStreamParser.java:541)
at 
org.eclipse.jetty.util.MultiPartInputStreamParser.getParts(MultiPartInputStreamParser.java:429)
at org.eclipse.jetty.server.Request.getParts(Request.java:2300)
at org.eclipse.jetty.server.Request.getParts(Request.java:2279)
{code}



> Camel Servlet, attachment object is empty
> -
>
> Key: CAMEL-10492
> URL: https://issues.apache.org/jira/browse/CAMEL-10492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common, camel-servlet
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Claus Ibsen
> Fix For: 2.18.1, 2.19.0
>
> Attachments: camel-example-servlet-attachment.zip
>
>
> I send a multipart form data to my camel servlet, before camel 2.18 
> attachment object is ok now is empty!
> Now i have an *header* every form field but every field is java.lang.String
> So, I can not post any binary file.
> This is my web.xml filter
> {code:xml}
>   
>   MultipartFilter
>   
> org.eclipse.jetty.servlets.MultiPartFilter
>   
>   
>   MultipartFilter
>   CamelServlet
>   
> {code}
> Into zip file, you can found an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

[Zoran Regvart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zoran Regvart closed CAMEL-10478.
-
Resolution: Won't Fix

There is no need for this, as outlined in [How to use a dynamic URI in 
to()|http://camel.apache.org/how-to-use-a-dynamic-uri-in-to.html]

> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683447#comment-15683447
 ] 

ASF GitHub Bot commented on CAMEL-10478:


Github user zregvart closed the pull request at:

https://github.com/apache/camel/pull/1274


> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683446#comment-15683446
 ] 

ASF GitHub Bot commented on CAMEL-10478:


Github user zregvart closed the pull request at:

https://github.com/apache/camel/pull/1273


> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10478) Support for simple language in message headers for camel-salesforce

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683445#comment-15683445
 ] 

ASF GitHub Bot commented on CAMEL-10478:


Github user zregvart closed the pull request at:

https://github.com/apache/camel/pull/1272


> Support for simple language in message headers for camel-salesforce
> ---
>
> Key: CAMEL-10478
> URL: https://issues.apache.org/jira/browse/CAMEL-10478
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.17.4, 2.18.1
> Environment: Any
>Reporter: Zoran Regvart
>
> Salesforce component could benefit greatly from supporting simple expressions 
> in header values. This would allow for natural chaining of salesforce 
> components for the `query` and `queryNext` operations, as former returns the 
> URL needed for the later.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10500) Camel-Git: Add allowEmpty commits option

[Andrea Cosentino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino resolved CAMEL-10500.
--
Resolution: Fixed

> Camel-Git: Add allowEmpty commits option 
> -
>
> Key: CAMEL-10500
> URL: https://issues.apache.org/jira/browse/CAMEL-10500
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
>Priority: Trivial
> Fix For: 2.19.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> By default, JGit behaves differently than native git allowing empty commits. 
> This first change is to add a new option to the GitEndpoint to be able to 
> turn that option to false. I let it default to "true" in a first move to have 
> backward compatibility but suggest we could default to "false" to match 
> native git behaviour (git commit --allow-empty)
> This will raise an exception for empty commits, may be a silent mode to log 
> warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10501) Allow Salesforce Maven plugin to run without Maven project

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683403#comment-15683403
 ] 

ASF GitHub Bot commented on CAMEL-10501:


GitHub user zregvart opened a pull request:

https://github.com/apache/camel/pull/1285

CAMEL-10501 Allow Salesforce Maven plugin to run without Maven project

Adds `requiresProject = false` to `@Mojo` annotation which allows the
camel-salesforce-maven-plugin to work in a directory without Maven
project (without pom.xml).

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zregvart/camel CAMEL-10501

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1285.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 #1285


commit 73122fa0e36a101d8688d86b92e10aebca9a6c4b
Author: Zoran Regvart 
Date:   2016-11-21T11:16:36Z

Salesforce Maven plugin: run without Maven project

Adds `requiresProject = false` to `@Mojo` annotation which allows the
camel-salesforce-maven-plugin to work in a directory without Maven
project (without pom.xml).




> Allow Salesforce Maven plugin to run without Maven project
> --
>
> Key: CAMEL-10501
> URL: https://issues.apache.org/jira/browse/CAMEL-10501
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-salesforce
>Affects Versions: 2.19.0
>Reporter: Zoran Regvart
>Priority: Minor
>
> Add _requiresProject = false_ to _@Mojo_ annotation that allows the 
> camel-salesforce-maven-plugin to work in without Maven project (directory 
> without pom.xml).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10501) Allow Salesforce Maven plugin to run without Maven project

[Zoran Regvart (JIRA)]

Zoran Regvart created CAMEL-10501:
-

 Summary: Allow Salesforce Maven plugin to run without Maven project
 Key: CAMEL-10501
 URL: https://issues.apache.org/jira/browse/CAMEL-10501
 Project: Camel
  Issue Type: Improvement
  Components: camel-salesforce
Affects Versions: 2.19.0
Reporter: Zoran Regvart
Priority: Minor


Add _requiresProject = false_ to _@Mojo_ annotation that allows the 
camel-salesforce-maven-plugin to work in without Maven project (directory 
without pom.xml).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10500) Camel-Git: Add allowEmpty commits option

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683384#comment-15683384
 ] 

ASF GitHub Bot commented on CAMEL-10500:


GitHub user chenapan opened a pull request:

https://github.com/apache/camel/pull/1284

CAMEL-10500 Camel-Git: Add allowEmpty commits option



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/chenapan/camel master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1284.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 #1284


commit fa09f3ef6f74badb8b18f6a94d93921b743a1235
Author: Olivier Antibi 
Date:   2016-11-20T21:43:15Z

Add allowEmpty endpoint option

commit 25a92fd0257106fe36a5e4bcb0e58268a8db777b
Author: Olivier Antibi 
Date:   2016-11-21T10:31:28Z

CAMEL-10500 : Camel-Git: Add allowEmpty commits option
Formatting and check style




> Camel-Git: Add allowEmpty commits option 
> -
>
> Key: CAMEL-10500
> URL: https://issues.apache.org/jira/browse/CAMEL-10500
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
>Priority: Trivial
> Fix For: 2.19.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> By default, JGit behaves differently than native git allowing empty commits. 
> This first change is to add a new option to the GitEndpoint to be able to 
> turn that option to false. I let it default to "true" in a first move to have 
> backward compatibility but suggest we could default to "false" to match 
> native git behaviour (git commit --allow-empty)
> This will raise an exception for empty commits, may be a silent mode to log 
> warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10487) Springboot commands : logback

[Evgeny Minkevich (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683358#comment-15683358
 ] 

Evgeny Minkevich commented on CAMEL-10487:
--

Looks like that while it is slf4j as the API the binding behind it is logback.

I got a quick fix here:

https://github.com/evmin/springboot-shell-logback

Could you pls check? If it something acceptable I will create a PR.


> Springboot commands : logback
> -
>
> Key: CAMEL-10487
> URL: https://issues.apache.org/jira/browse/CAMEL-10487
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-spring-boot
>Reporter: Evgeny Minkevich
>
> As a system operator I would like to be able to change the log level of the 
> Camel ecosystem via Springboot remote shell command line.
> At the moment only java.util.logging set of commands is present - "jul" - and 
> it does not work for the Camel components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10499) camel-sql - error in multiple dynamic IN replacement

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683346#comment-15683346
 ] 

ASF GitHub Bot commented on CAMEL-10499:


Github user igarashitm closed the pull request at:

https://github.com/apache/camel/pull/1283


> camel-sql - error in multiple dynamic IN replacement
> 
>
> Key: CAMEL-10499
> URL: https://issues.apache.org/jira/browse/CAMEL-10499
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.18.0
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
> Fix For: 2.18.1, 2.19.0
>
>
> Having this sql
> {code:sql}
> select *
> from projects
> where project in (:#in:names)
> and license in (:#in:licenses)
> order by id
> {code}
> and send as following
> {code:java}
> Map headers = new HashMap<>();
> headers.put("names", new String[]{"Camel", "AMQ"});
> headers.put("licenses", new String[]{"ASF", "XXX", "YYY"});
> template.requestBodyAndHeaders("direct:query", "Hi there!", headers);
> {code}
> causes parameter mismatch
> {code}
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected: 4, 
> was: 5
> at 
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:152)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:146)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:116)
>  ~[classes/:?]
> at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:633) 
> ~[spring-jdbc-4.3.4.RELEASE.jar:4.3.4.RELEASE]
> ... 51 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10499) camel-sql - error in multiple dynamic IN replacement

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-10499.
-
   Resolution: Fixed
Fix Version/s: (was: 2.18.2)
   2.18.1

Thanks

> camel-sql - error in multiple dynamic IN replacement
> 
>
> Key: CAMEL-10499
> URL: https://issues.apache.org/jira/browse/CAMEL-10499
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.18.0
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
> Fix For: 2.18.1, 2.19.0
>
>
> Having this sql
> {code:sql}
> select *
> from projects
> where project in (:#in:names)
> and license in (:#in:licenses)
> order by id
> {code}
> and send as following
> {code:java}
> Map headers = new HashMap<>();
> headers.put("names", new String[]{"Camel", "AMQ"});
> headers.put("licenses", new String[]{"ASF", "XXX", "YYY"});
> template.requestBodyAndHeaders("direct:query", "Hi there!", headers);
> {code}
> causes parameter mismatch
> {code}
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected: 4, 
> was: 5
> at 
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:152)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:146)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:116)
>  ~[classes/:?]
> at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:633) 
> ~[spring-jdbc-4.3.4.RELEASE.jar:4.3.4.RELEASE]
> ... 51 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10477) [jruby] Upgrade to 1.7.26

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683254#comment-15683254
 ] 

ASF GitHub Bot commented on CAMEL-10477:


Github user tdiesler closed the pull request at:

https://github.com/apache/camel/pull/1282


> [jruby] Upgrade to 1.7.26
> -
>
> Key: CAMEL-10477
> URL: https://issues.apache.org/jira/browse/CAMEL-10477
> Project: Camel
>  Issue Type: Task
>  Components: camel-script
>Affects Versions: 2.18.0
>Reporter: Paolo Antinori
>Assignee: Paolo Antinori
>Priority: Minor
> Fix For: 2.19.0
>
>
> Upgrade {{jruby}} to {{v1.7.26}}
> Note: this requires to explicitly set in test, while in used in multithread 
> envs.
> {code}
> System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10477) [jruby] Upgrade to 1.7.26

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683131#comment-15683131
 ] 

ASF GitHub Bot commented on CAMEL-10477:


GitHub user tdiesler opened a pull request:

https://github.com/apache/camel/pull/1282

Revert "CAMEL-10477 - jruby 1.7.26"

This reverts commit 057bbaeab3a947b67803ed500d9565bb63d105e8.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tdiesler/camel CAMEL-10477

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1282.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 #1282


commit 1bfd1a76acca3fc460e3bf9e8f318312e8356922
Author: Thomas Diesler 
Date:   2016-11-21T10:09:43Z

Revert "CAMEL-10477 - jruby 1.7.26"

This reverts commit 057bbaeab3a947b67803ed500d9565bb63d105e8.




> [jruby] Upgrade to 1.7.26
> -
>
> Key: CAMEL-10477
> URL: https://issues.apache.org/jira/browse/CAMEL-10477
> Project: Camel
>  Issue Type: Task
>  Components: camel-script
>Affects Versions: 2.18.0
>Reporter: Paolo Antinori
>Assignee: Paolo Antinori
>Priority: Minor
> Fix For: 2.19.0
>
>
> Upgrade {{jruby}} to {{v1.7.26}}
> Note: this requires to explicitly set in test, while in used in multithread 
> envs.
> {code}
> System.setProperty("org.jruby.embed.localcontext.scope", "threadsafe")
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10477) [jruby] Upgrade to 1.7.26

[Thomas Diesler (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683128#comment-15683128
 ] 

Thomas Diesler commented on CAMEL-10477:


This upgrade frequently causes 

{code}
Caused by: org.jruby.embed.EvalFailedException: (NoMethodError) undefined 
method `getBody' for nil:NilClass
at 
org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:132)
at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:90)
at 
org.apache.camel.builder.script.ScriptBuilder.runScript(ScriptBuilder.java:469)
at 
org.apache.camel.builder.script.ScriptBuilder.doEvaluateScript(ScriptBuilder.java:428)
at 
org.apache.camel.builder.script.ScriptBuilder.evaluateScript(ScriptBuilder.java:409)
... 151 more
Caused by: org.jruby.exceptions.RaiseException: (NoMethodError) undefined 
method `getBody' for nil:NilClass
at 

[jira] [Commented] (CAMEL-10487) Springboot commands : logback

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683068#comment-15683068
 ] 

Claus Ibsen commented on CAMEL-10487:
-

Can you find out more, because Camel uses slf4j-api for its logging. So I 
wonder if there is anything to be changed/done on Apache Camel side of things. 

Can't spring boot configure logging for slf4j also?

> Springboot commands : logback
> -
>
> Key: CAMEL-10487
> URL: https://issues.apache.org/jira/browse/CAMEL-10487
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-spring-boot
>Reporter: Evgeny Minkevich
>
> As a system operator I would like to be able to change the log level of the 
> Camel ecosystem via Springboot remote shell command line.
> At the moment only java.util.logging set of commands is present - "jul" - and 
> it does not work for the Camel components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10490) JpaPollingConsumer does not support consumeLockEntity and others

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683065#comment-15683065
 ] 

Claus Ibsen commented on CAMEL-10490:
-

We love contributions. So you are welcome to do a patch / PR
http://camel.apache.org/contributing

> JpaPollingConsumer does not support consumeLockEntity and others
> 
>
> Key: CAMEL-10490
> URL: https://issues.apache.org/jira/browse/CAMEL-10490
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jpa
>Affects Versions: 2.18.0
>Reporter: Bob Gaudaen
> Fix For: 2.18.2, 2.19.0
>
>
> Since the introduction of JpaPollingConsumer in camel 2.18.0, it is not 
> possible anymore to use some of jpa consumer options (consumeLockEntity, 
> consumeDelete, ...).
> Documentation also lacks some information on which option can be used by the 
> jpa consumer and not by the polling consumer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10490) JpaPollingConsumer does not support consumeLockEntity and others

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10490:

Fix Version/s: 2.19.0
   2.18.2

> JpaPollingConsumer does not support consumeLockEntity and others
> 
>
> Key: CAMEL-10490
> URL: https://issues.apache.org/jira/browse/CAMEL-10490
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jpa
>Affects Versions: 2.18.0
>Reporter: Bob Gaudaen
> Fix For: 2.18.2, 2.19.0
>
>
> Since the introduction of JpaPollingConsumer in camel 2.18.0, it is not 
> possible anymore to use some of jpa consumer options (consumeLockEntity, 
> consumeDelete, ...).
> Documentation also lacks some information on which option can be used by the 
> jpa consumer and not by the polling consumer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10486) Google PubSub Component does not consume messages with parallel consumers

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10486:

Affects Version/s: (was: 2.19.0)

> Google PubSub Component does not consume messages with parallel consumers
> -
>
> Key: CAMEL-10486
> URL: https://issues.apache.org/jira/browse/CAMEL-10486
> Project: Camel
>  Issue Type: Bug
>Reporter: Evgeny Minkevich
> Fix For: 2.19.0
>
>
> Component: camel-google-pubsub
> When parallelConsumers option on an endpoint is assigned the value greater 
> than 1, the component will not be receiving messages.
> The issue has been traced to the underlying Google library used and I will 
> update the component once the fix is available. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10492) Camel Servlet, attachment object is empty

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-10492.
-
   Resolution: Fixed
 Assignee: Claus Ibsen
Fix Version/s: 2.19.0
   2.18.1

> Camel Servlet, attachment object is empty
> -
>
> Key: CAMEL-10492
> URL: https://issues.apache.org/jira/browse/CAMEL-10492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common, camel-servlet
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
>Assignee: Claus Ibsen
> Fix For: 2.18.1, 2.19.0
>
> Attachments: camel-example-servlet-attachment.zip
>
>
> I send a multipart form data to my camel servlet, before camel 2.18 
> attachment object is ok now is empty!
> Now i have an *header* every form field but every field is java.lang.String
> So, I can not post any binary file.
> This is my web.xml filter
> {code:xml}
>   
>   MultipartFilter
>   
> org.eclipse.jetty.servlets.MultiPartFilter
>   
>   
>   MultipartFilter
>   CamelServlet
>   
> {code}
> Into zip file, you can found an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10486) Google PubSub Component does not consume messages with parallel consumers

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10486:

Fix Version/s: 2.19.0

> Google PubSub Component does not consume messages with parallel consumers
> -
>
> Key: CAMEL-10486
> URL: https://issues.apache.org/jira/browse/CAMEL-10486
> Project: Camel
>  Issue Type: Bug
>Reporter: Evgeny Minkevich
> Fix For: 2.19.0
>
>
> Component: camel-google-pubsub
> When parallelConsumers option on an endpoint is assigned the value greater 
> than 1, the component will not be receiving messages.
> The issue has been traced to the underlying Google library used and I will 
> update the component once the fix is available. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10492) Camel Servlet, attachment object is empty

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683059#comment-15683059
 ] 

Claus Ibsen commented on CAMEL-10492:
-

I made it possible to configure this on endpoint in next release.

> Camel Servlet, attachment object is empty
> -
>
> Key: CAMEL-10492
> URL: https://issues.apache.org/jira/browse/CAMEL-10492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common, camel-servlet
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
> Attachments: camel-example-servlet-attachment.zip
>
>
> I send a multipart form data to my camel servlet, before camel 2.18 
> attachment object is ok now is empty!
> Now i have an *header* every form field but every field is java.lang.String
> So, I can not post any binary file.
> This is my web.xml filter
> {code:xml}
>   
>   MultipartFilter
>   
> org.eclipse.jetty.servlets.MultiPartFilter
>   
>   
>   MultipartFilter
>   CamelServlet
>   
> {code}
> Into zip file, you can found an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10492) Camel Servlet, attachment object is empty

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683044#comment-15683044
 ] 

Claus Ibsen commented on CAMEL-10492:
-

You need to turn set that = true on the servlet component.

Add a bean configuration in your xml file


  



> Camel Servlet, attachment object is empty
> -
>
> Key: CAMEL-10492
> URL: https://issues.apache.org/jira/browse/CAMEL-10492
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http-common, camel-servlet
>Affects Versions: 2.18.0
>Reporter: Fabrizio Spataro
> Attachments: camel-example-servlet-attachment.zip
>
>
> I send a multipart form data to my camel servlet, before camel 2.18 
> attachment object is ok now is empty!
> Now i have an *header* every form field but every field is java.lang.String
> So, I can not post any binary file.
> This is my web.xml filter
> {code:xml}
>   
>   MultipartFilter
>   
> org.eclipse.jetty.servlets.MultiPartFilter
>   
>   
>   MultipartFilter
>   CamelServlet
>   
> {code}
> Into zip file, you can found an example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CAMEL-10496) Component fails at runtime with exception with SpringBoot

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen resolved CAMEL-10496.
-
Resolution: Duplicate

See CAMEL-10465

> Component fails at runtime with exception with SpringBoot
> -
>
> Key: CAMEL-10496
> URL: https://issues.apache.org/jira/browse/CAMEL-10496
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ahc-ws
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
>
> Using the following dependencies
>   compile('org.apache.camel:camel-jackson-starter:2.18.0')
>   compile('org.apache.camel:camel-metrics-starter:2.18.0')
>   compile('org.apache.camel:camel-rabbitmq-starter:2.18.0')
>   compile('org.apache.camel:camel-spring-boot-starter:2.18.0')
>   compile('org.apache.camel:camel-spring-redis-starter:2.18.0')
>   compile('org.apache.camel:camel-stream-starter:2.18.0')
> compile('org.apache.camel:camel-ahc-ws-starter:2.18.0')
> compile('org.springframework.boot:spring-boot-actuator')
> compile("org.springframework.boot:spring-boot-starter-web")
> And the following ahc-ws definition in Spring Boot
> .
> .multicast()
> .parallelProcessing()
> .pipeline()
> .marshal().json(JsonLibrary.Jackson)
> .convertBodyTo(String.class)  // Avoids string serialization issues 
> in websocket component.
> .to("ahc-ws://localhost:8080/votes?sendToAll=true")
> .end()
> .
> At runtime I get the following error when publishing to this sink
> (This also happens in test cases without the multicast etc)
> java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
> Invalid Status Code 404
> at 
> org.asynchttpclient.netty.NettyResponseFuture.done(NettyResponseFuture.java:228)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> org.asynchttpclient.netty.handler.WebSocketHandler$UpgradeCallback.call(WebSocketHandler.java:100)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> org.asynchttpclient.netty.handler.AsyncHttpClientHandler.channelRead(AsyncHttpClientHandler.java:73)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:435)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
>  ~[netty-codec-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
>  ~[netty-codec-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:250)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> 

[jira] [Updated] (CAMEL-10496) Component fails at runtime with exception with SpringBoot

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10496:

Priority: Minor  (was: Blocker)

> Component fails at runtime with exception with SpringBoot
> -
>
> Key: CAMEL-10496
> URL: https://issues.apache.org/jira/browse/CAMEL-10496
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ahc-ws
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
>
> Using the following dependencies
>   compile('org.apache.camel:camel-jackson-starter:2.18.0')
>   compile('org.apache.camel:camel-metrics-starter:2.18.0')
>   compile('org.apache.camel:camel-rabbitmq-starter:2.18.0')
>   compile('org.apache.camel:camel-spring-boot-starter:2.18.0')
>   compile('org.apache.camel:camel-spring-redis-starter:2.18.0')
>   compile('org.apache.camel:camel-stream-starter:2.18.0')
> compile('org.apache.camel:camel-ahc-ws-starter:2.18.0')
> compile('org.springframework.boot:spring-boot-actuator')
> compile("org.springframework.boot:spring-boot-starter-web")
> And the following ahc-ws definition in Spring Boot
> .
> .multicast()
> .parallelProcessing()
> .pipeline()
> .marshal().json(JsonLibrary.Jackson)
> .convertBodyTo(String.class)  // Avoids string serialization issues 
> in websocket component.
> .to("ahc-ws://localhost:8080/votes?sendToAll=true")
> .end()
> .
> At runtime I get the following error when publishing to this sink
> (This also happens in test cases without the multicast etc)
> java.util.concurrent.ExecutionException: java.lang.IllegalStateException: 
> Invalid Status Code 404
> at 
> org.asynchttpclient.netty.NettyResponseFuture.done(NettyResponseFuture.java:228)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> org.asynchttpclient.netty.handler.WebSocketHandler$UpgradeCallback.call(WebSocketHandler.java:100)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> org.asynchttpclient.netty.handler.AsyncHttpClientHandler.channelRead(AsyncHttpClientHandler.java:73)
>  ~[async-http-client-2.0.15.jar:na]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:435)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293)
>  ~[netty-codec-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267)
>  ~[netty-codec-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:250)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:345)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1294)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:911)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
>  ~[netty-transport-4.0.41.Final.jar:4.0.41.Final]
> at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:611) 

[jira] [Updated] (CAMEL-10497) Improve documentation detailing websocket implementation details

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10497:

Component/s: documentation

> Improve documentation detailing websocket implementation details
> 
>
> Key: CAMEL-10497
> URL: https://issues.apache.org/jira/browse/CAMEL-10497
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-websocket, documentation
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
> Fix For: Future
>
>
> Improve behavior documentation of this component, specifically around port 
> workflows.
> While the initial port can be declaratively exposed for clients to connect 
> the component opens up two random(?) ports per client connected rather than 
> communicate through the single exposed port declared.
> This was not apparent from the documentation and makes this component 
> somewhat inappropriate for containerization which would be useful to consider 
> when evaluating the 3 websocket implementations currently available for Camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10497) Improve documentation detailing websocket implementation details

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10497:

Fix Version/s: Future

> Improve documentation detailing websocket implementation details
> 
>
> Key: CAMEL-10497
> URL: https://issues.apache.org/jira/browse/CAMEL-10497
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-websocket, documentation
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
> Fix For: Future
>
>
> Improve behavior documentation of this component, specifically around port 
> workflows.
> While the initial port can be declaratively exposed for clients to connect 
> the component opens up two random(?) ports per client connected rather than 
> communicate through the single exposed port declared.
> This was not apparent from the documentation and makes this component 
> somewhat inappropriate for containerization which would be useful to consider 
> when evaluating the 3 websocket implementations currently available for Camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10497) Improve documentation detailing websocket implementation details

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683027#comment-15683027
 ] 

Claus Ibsen commented on CAMEL-10497:
-

Contributions is welcome to update the docs at
https://github.com/apache/camel/blob/master/components/camel-websocket/src/main/docs/websocket-component.adoc

> Improve documentation detailing websocket implementation details
> 
>
> Key: CAMEL-10497
> URL: https://issues.apache.org/jira/browse/CAMEL-10497
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-websocket, documentation
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
> Fix For: Future
>
>
> Improve behavior documentation of this component, specifically around port 
> workflows.
> While the initial port can be declaratively exposed for clients to connect 
> the component opens up two random(?) ports per client connected rather than 
> communicate through the single exposed port declared.
> This was not apparent from the documentation and makes this component 
> somewhat inappropriate for containerization which would be useful to consider 
> when evaluating the 3 websocket implementations currently available for Camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10466) OOM in Dropbox component (uses ByteArrayOutputStream for get)

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10466:

Affects Version/s: 2.18.0

> OOM in Dropbox component (uses ByteArrayOutputStream for get)
> -
>
> Key: CAMEL-10466
> URL: https://issues.apache.org/jira/browse/CAMEL-10466
> Project: Camel
>  Issue Type: Bug
>  Components: camel-dropbox
>Affects Versions: 2.18.0
>Reporter: Edoardo Causarano
>  Labels: out-of-memory
> Fix For: 2.18.2, 2.19.0
>
>
> Using the Dropbox component to download files will consume large amounts of 
> memory, often producing OOMs.
> This is due to the use of ByteArrayOutputStream objects in the implementation 
> of org.apache.camel.component.dropbox.core.DropboxAPIFacade
> The component should use 
> org.apache.camel.converter.stream.OutputStreamBuilder instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10497) Improve documentation detailing websocket implementation details

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10497:

Estimated Complexity: Novice  (was: Unknown)

> Improve documentation detailing websocket implementation details
> 
>
> Key: CAMEL-10497
> URL: https://issues.apache.org/jira/browse/CAMEL-10497
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-websocket
>Affects Versions: 2.18.0
>Reporter: Stuart Ingram
>Priority: Minor
>
> Improve behavior documentation of this component, specifically around port 
> workflows.
> While the initial port can be declaratively exposed for clients to connect 
> the component opens up two random(?) ports per client connected rather than 
> communicate through the single exposed port declared.
> This was not apparent from the documentation and makes this component 
> somewhat inappropriate for containerization which would be useful to consider 
> when evaluating the 3 websocket implementations currently available for Camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10466) OOM in Dropbox component (uses ByteArrayOutputStream for get)

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10466:

Component/s: camel-dropbox

> OOM in Dropbox component (uses ByteArrayOutputStream for get)
> -
>
> Key: CAMEL-10466
> URL: https://issues.apache.org/jira/browse/CAMEL-10466
> Project: Camel
>  Issue Type: Bug
>  Components: camel-dropbox
>Affects Versions: 2.18.0
>Reporter: Edoardo Causarano
>  Labels: out-of-memory
> Fix For: 2.18.2, 2.19.0
>
>
> Using the Dropbox component to download files will consume large amounts of 
> memory, often producing OOMs.
> This is due to the use of ByteArrayOutputStream objects in the implementation 
> of org.apache.camel.component.dropbox.core.DropboxAPIFacade
> The component should use 
> org.apache.camel.converter.stream.OutputStreamBuilder instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10466) OOM in Dropbox component (uses ByteArrayOutputStream for get)

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10466:

Fix Version/s: 2.18.2

> OOM in Dropbox component (uses ByteArrayOutputStream for get)
> -
>
> Key: CAMEL-10466
> URL: https://issues.apache.org/jira/browse/CAMEL-10466
> Project: Camel
>  Issue Type: Bug
>Reporter: Edoardo Causarano
>  Labels: out-of-memory
> Fix For: 2.18.2, 2.19.0
>
>
> Using the Dropbox component to download files will consume large amounts of 
> memory, often producing OOMs.
> This is due to the use of ByteArrayOutputStream objects in the implementation 
> of org.apache.camel.component.dropbox.core.DropboxAPIFacade
> The component should use 
> org.apache.camel.converter.stream.OutputStreamBuilder instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10466) OOM in Dropbox component (uses ByteArrayOutputStream for get)

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10466:

Fix Version/s: 2.19.0

> OOM in Dropbox component (uses ByteArrayOutputStream for get)
> -
>
> Key: CAMEL-10466
> URL: https://issues.apache.org/jira/browse/CAMEL-10466
> Project: Camel
>  Issue Type: Bug
>Reporter: Edoardo Causarano
>  Labels: out-of-memory
> Fix For: 2.18.2, 2.19.0
>
>
> Using the Dropbox component to download files will consume large amounts of 
> memory, often producing OOMs.
> This is due to the use of ByteArrayOutputStream objects in the implementation 
> of org.apache.camel.component.dropbox.core.DropboxAPIFacade
> The component should use 
> org.apache.camel.converter.stream.OutputStreamBuilder instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10466) OOM in Dropbox component (uses ByteArrayOutputStream for get)

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683022#comment-15683022
 ] 

Claus Ibsen commented on CAMEL-10466:
-

unable to find remote file, at what point can this happen? Is it on a consumer 
or producer side? Can you point out to where this is in your code?

> OOM in Dropbox component (uses ByteArrayOutputStream for get)
> -
>
> Key: CAMEL-10466
> URL: https://issues.apache.org/jira/browse/CAMEL-10466
> Project: Camel
>  Issue Type: Bug
>Reporter: Edoardo Causarano
>  Labels: out-of-memory
> Fix For: 2.18.2, 2.19.0
>
>
> Using the Dropbox component to download files will consume large amounts of 
> memory, often producing OOMs.
> This is due to the use of ByteArrayOutputStream objects in the implementation 
> of org.apache.camel.component.dropbox.core.DropboxAPIFacade
> The component should use 
> org.apache.camel.converter.stream.OutputStreamBuilder instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10363) camel-spring-redis - Cannot install in Karaf

[Claus Ibsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15683013#comment-15683013
 ] 

Claus Ibsen commented on CAMEL-10363:
-

[~jbonofre] did you implement this in karaf? And is there a KARAF ticket we can 
link to?

> camel-spring-redis - Cannot install in Karaf
> 
>
> Key: CAMEL-10363
> URL: https://issues.apache.org/jira/browse/CAMEL-10363
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-redis, karaf, osgi
>Affects Versions: 2.18.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.2, 2.19.0
>
>
> Sadly it seems redis is locked down to version 1.7.12 of slf4j, and not just 
> 1.7.x etc.
> {code}
> karaf@root()> feature:install camel-spring-redis
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=camel-spring-redis; type=karaf.feature; 
> version="[2.18.0.SNAPSHOT,2.18.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=camel-spring-redis)(type=karaf.feature)(version>=2.18.0.SNAPSHOT)(version<=2.18.0.SNAPSHOT))"
>  [caused by: Unable to resolve camel-spring-redis/2.18.0.SNAPSHOT: missing 
> requirement [camel-spring-redis/2.18.0.SNAPSHOT] osgi.identity; 
> osgi.identity=slf4j.api; type=osgi.bundle; version="[1.7.12,1.7.12]"; 
> resolution:=mandatory [caused by: Unable to resolve slf4j.api/1.7.12: missing 
> requirement [slf4j.api/1.7.12] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))"]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10499) camel-sql - error in multiple dynamic IN replacement

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10499:

Fix Version/s: 2.19.0
   2.18.2

> camel-sql - error in multiple dynamic IN replacement
> 
>
> Key: CAMEL-10499
> URL: https://issues.apache.org/jira/browse/CAMEL-10499
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.18.0
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
> Fix For: 2.18.2, 2.19.0
>
>
> Having this sql
> {code:sql}
> select *
> from projects
> where project in (:#in:names)
> and license in (:#in:licenses)
> order by id
> {code}
> and send as following
> {code:java}
> Map headers = new HashMap<>();
> headers.put("names", new String[]{"Camel", "AMQ"});
> headers.put("licenses", new String[]{"ASF", "XXX", "YYY"});
> template.requestBodyAndHeaders("direct:query", "Hi there!", headers);
> {code}
> causes parameter mismatch
> {code}
> Caused by: java.sql.SQLException: Number of parameters mismatch. Expected: 4, 
> was: 5
> at 
> org.apache.camel.component.sql.DefaultSqlPrepareStatementStrategy.populateStatement(DefaultSqlPrepareStatementStrategy.java:152)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:146)
>  ~[classes/:?]
> at 
> org.apache.camel.component.sql.SqlProducer$2.doInPreparedStatement(SqlProducer.java:116)
>  ~[classes/:?]
> at 
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:633) 
> ~[spring-jdbc-4.3.4.RELEASE.jar:4.3.4.RELEASE]
> ... 51 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10301) NullPointerException in Netty4 component's ClientChannelHandler causes async processor to wait forever

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10301:

Fix Version/s: (was: 2.18.1)
   2.18.2

> NullPointerException in Netty4 component's ClientChannelHandler causes async 
> processor to wait forever
> --
>
> Key: CAMEL-10301
> URL: https://issues.apache.org/jira/browse/CAMEL-10301
> Project: Camel
>  Issue Type: Bug
>  Components: camel-netty4
>Affects Versions: 2.17.2
>Reporter: Alex Cheng
> Fix For: 2.18.2, 2.19.0
>
>
> When sending messages using camel netty4 component, in a rare case, a 
> NullPointerException thrown in {{ClientChannelHandler}} caused 
> {{org.apache.camel.impl.DefaultAsyncProcessorAwaitManager}} to wait forever. 
> From the stacktrace, the NPE occurred in line 116 of {{channelInactive}} 
> method and the {{exchange}} is null.
> {code}
> boolean doneUoW = exchange.getUnitOfWork() == null;
> {code}
> From {{getExchange}} method, it looks like it cannot get {{NettyCamelState}} 
> from {{NettyProducer}}. In {{NettyProducer}}'s {{process}} method, it's 
> possible that a Netty channel is closed before line 
> {code}
> putState(channel, new NettyCamelState(producerCallback, exchange));
> {code}
>  is executed, which triggers {{channelInactive}} and causes the NPE.
> So the flow looks like below:
> 1) Netty channel opened in {{NettyProducer}}
> 2) Before {{putState}} is invoked, the channel is closed
> 3) {{channelInactive}} method in {{ClientChannelHandler}} is called and 
> throws NPE, the worker thread dies
> 4) {{NettyProducer}} not mark the async processor as done
> In line 303 of {{NettyProducer}}, it simply returns if the channel future is 
> not success, but the {{ClientChannelHandler#exceptionCaught}} won't do any 
> thing if {{exchange}} is null and will never run again as the worker thread 
> already died.
> {code}
> if (!channelFuture.isSuccess()) {
> // no success then exit, (any exception has been handled 
> by ClientChannelHandler#exceptionCaught)
> return;
> }
> {code}
> The potential fix would be:
> 1) Add null check in {{ClientChannelHandler}}'s {{channelInactive}} method
> 2) Call {{producerCallback.done(false)}} in {{NettyProducer}}'s {{process}} 
> method when channel future is not success. This should be safe as 
> {{AsyncCallback}}'s {{done}} method can be called multiple times.
> Note, 2.18.0 version changed some implementation details of {{NettyProducer}} 
> but still has the same issue.
> Stacktrace:
> {code}
> 2016-09-08 00:26:11,843 | TRACE [-threads-1855599236)]
> org.apache.camel.component.netty4.NettyProducer : Pool[active=0, idle=0]
> 2016-09-08 00:26:11,843 | DEBUG [-threads-1855599236)]
> org.apache.camel.component.netty4.NettyProducer : Created new TCP client 
> bootstrap connecting to 172.25.0.100:15050 with options: 
> Bootstrap(BootstrapConfig(group: NioEventLoopGroup, channelFactory: 
> NioSocketChannel.class, options: {SO_KEEPALIVE=true, TCP_NODELAY=true, 
> SO_REUSEADDR=true, CONNECT_TIMEOUT_MILLIS=1}, handler: 
> org.apache.camel.component.netty4.DefaultClientInitializerFactory@297c237, 
> resolver: io.netty.resolver.DefaultAddressResolverGroup@6eb474f1))
> 2016-09-08 00:26:11,843 | TRACE [-threads-1855599236)]
> org.apache.camel.component.netty4.NettyProducer : Waiting for operation to 
> complete AbstractBootstrap$PendingRegistrationPromise@637319e7(incomplete) 
> for 1 millis
> 2016-09-08 00:26:11,844 | TRACE [NettyClientTCPWorker] 
> o.a.c.c.netty4.DefaultClientInitializerFactory : Using request timeout 5000 
> millis
> 2016-09-08 00:26:11,844 | TRACE [NettyClientTCPWorker] 
> o.a.c.c.netty4.DefaultClientInitializerFactory : Created ChannelPipeline: 
> DefaultChannelPipeline{(DefaultClientInitializerFactory#0 = 
> org.apache.camel.component.netty4.DefaultClientInitializerFactory), 
> (decoder-0 = xxx), (encoder-0 = 
> org.apache.camel.component.hl7.HL7MLLPNettyEncoder), (timeout = 
> io.netty.handler.timeout.ReadTimeoutHandler), (handler = 
> org.apache.camel.component.netty4.handlers.ClientChannelHandler)}
> 2016-09-08 00:26:11,845 | DEBUG [-threads-1855599236)]
> org.apache.camel.component.netty4.NettyProducer : Creating connector to 
> address: 172.25.0.100:15050
> 2016-09-08 00:26:11,845 | TRACE [NettyClientTCPWorker]
> org.apache.camel.component.netty4.NettyProducer : Channel open: [id: 
> 0x40064baa, L:/172.25.0.103:55662 - R:/172.25.0.100:15050]
> 2016-09-08 00:26:11,845 | TRACE [-threads-1855599236)]
> org.apache.camel.component.netty4.NettyProducer : Created channel: [id: 
> 0x40064baa, L:/172.25.0.103:55662 - R:/172.25.0.100:15050]
> 2016-09-08 00:26:11,845 | TRACE [-threads-1855599236)]

[jira] [Updated] (CAMEL-10363) camel-spring-redis - Cannot install in Karaf

[Claus Ibsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-10363:

Fix Version/s: (was: 2.18.1)
   2.18.2

> camel-spring-redis - Cannot install in Karaf
> 
>
> Key: CAMEL-10363
> URL: https://issues.apache.org/jira/browse/CAMEL-10363
> Project: Camel
>  Issue Type: Bug
>  Components: camel-spring-redis, karaf, osgi
>Affects Versions: 2.18.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.2, 2.19.0
>
>
> Sadly it seems redis is locked down to version 1.7.12 of slf4j, and not just 
> 1.7.x etc.
> {code}
> karaf@root()> feature:install camel-spring-redis
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=camel-spring-redis; type=karaf.feature; 
> version="[2.18.0.SNAPSHOT,2.18.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=camel-spring-redis)(type=karaf.feature)(version>=2.18.0.SNAPSHOT)(version<=2.18.0.SNAPSHOT))"
>  [caused by: Unable to resolve camel-spring-redis/2.18.0.SNAPSHOT: missing 
> requirement [camel-spring-redis/2.18.0.SNAPSHOT] osgi.identity; 
> osgi.identity=slf4j.api; type=osgi.bundle; version="[1.7.12,1.7.12]"; 
> resolution:=mandatory [caused by: Unable to resolve slf4j.api/1.7.12: missing 
> requirement [slf4j.api/1.7.12] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.slf4j.impl)(version>=1.6.0))"]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CAMEL-10500) Camel-Git: Add allowEmpty commits option

[Andrea Cosentino (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-10500:


Assignee: Andrea Cosentino

> Camel-Git: Add allowEmpty commits option 
> -
>
> Key: CAMEL-10500
> URL: https://issues.apache.org/jira/browse/CAMEL-10500
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Assignee: Andrea Cosentino
>Priority: Trivial
> Fix For: 2.19.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> By default, JGit behaves differently than native git allowing empty commits. 
> This first change is to add a new option to the GitEndpoint to be able to 
> turn that option to false. I let it default to "true" in a first move to have 
> backward compatibility but suggest we could default to "false" to match 
> native git behaviour (git commit --allow-empty)
> This will raise an exception for empty commits, may be a silent mode to log 
> warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CAMEL-10500) Camel-Git: Add allowEmpty commits option

[Olivier Antibi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-10500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Antibi updated CAMEL-10500:
---
Summary: Camel-Git: Add allowEmpty commits option   (was: Add allowEmpty 
commits option )

> Camel-Git: Add allowEmpty commits option 
> -
>
> Key: CAMEL-10500
> URL: https://issues.apache.org/jira/browse/CAMEL-10500
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-git
>Affects Versions: 2.18.0
>Reporter: Olivier Antibi
>Priority: Trivial
> Fix For: 2.19.0
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> By default, JGit behaves differently than native git allowing empty commits. 
> This first change is to add a new option to the GitEndpoint to be able to 
> turn that option to false. I let it default to "true" in a first move to have 
> backward compatibility but suggest we could default to "false" to match 
> native git behaviour (git commit --allow-empty)
> This will raise an exception for empty commits, may be a silent mode to log 
> warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-10500) Add allowEmpty commits option

[Olivier Antibi (JIRA)]

Olivier Antibi created CAMEL-10500:
--

 Summary: Add allowEmpty commits option 
 Key: CAMEL-10500
 URL: https://issues.apache.org/jira/browse/CAMEL-10500
 Project: Camel
  Issue Type: Improvement
  Components: camel-git
Affects Versions: 2.18.0
Reporter: Olivier Antibi
Priority: Trivial
 Fix For: 2.19.0


By default, JGit behaves differently than native git allowing empty commits. 
This first change is to add a new option to the GitEndpoint to be able to turn 
that option to false. I let it default to "true" in a first move to have 
backward compatibility but suggest we could default to "false" to match native 
git behaviour (git commit --allow-empty)

This will raise an exception for empty commits, may be a silent mode to log 
warn would be a better option rather than doing error handling in camel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-10481) Camel does not expose cassandra-all any more

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-10481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682847#comment-15682847
 ] 

ASF GitHub Bot commented on CAMEL-10481:


Github user tdiesler closed the pull request at:

https://github.com/apache/camel/pull/1275


> Camel does not expose cassandra-all any more
> 
>
> Key: CAMEL-10481
> URL: https://issues.apache.org/jira/browse/CAMEL-10481
> Project: Camel
>  Issue Type: Task
>  Components: build system
>Reporter: Thomas Diesler
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.19.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)