[jira] [Resolved] (CAMEL-9791) DeadLetterChannel not triggered on RejectedExecutionException

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9791.

Resolution: Fixed

> DeadLetterChannel not triggered on RejectedExecutionException
> -
>
> Key: CAMEL-9791
> URL: https://issues.apache.org/jira/browse/CAMEL-9791
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Thibaut Robert
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.0
>
> Attachments: ThreadsRejectedExecutionWithDeadLetterTest.java
>
>
> I use a thread processor to implement multi-threading
> I wish that the deadletter endpoint of the route to be called when the pool 
> reject the execution of the task (to save the message on disk)
> However, whatever the rejectedPolicy I choose, the rejected exchange is just 
> dropped because the exchange is marked with routeStop and redeliveryExhausted.
> I think it's correct to not redeliver (we are lacking resources, replaying 
> won't help), but there should at least be a way to handle the failed message 
> somehow.



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

[jira] [Commented] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9808:


See here how to be able to edit the docs
http://camel.apache.org/how-do-i-edit-the-website.html

I have updated the wiki page with the new option

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Created] (CAMEL-9814) Support a parent configuration for routes to inherit properties for the CamelContext

[Matt Pavlovich (JIRA)]

Matt Pavlovich created CAMEL-9814:
-

 Summary: Support a parent configuration for routes to inherit 
properties for the CamelContext
 Key: CAMEL-9814
 URL: https://issues.apache.org/jira/browse/CAMEL-9814
 Project: Camel
  Issue Type: New Feature
  Components: camel-core, camel-osgi
Reporter: Matt Pavlovich
 Fix For: 3.0.0


It would be really handy to have a top-level configuration that Contexts and 
Routes can inherit a set of default values.

This would allow developers to reduce the complexity and verboseness of routes 
as well as allow administrators to set defaults for an environment.

Types of settings:

Tracing: on/off
Jmx Enabled, mbean port, URL, etc
DefaultShutdownStrategy timeout
etc.





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

[jira] [Commented] (CAMEL-9754) Convert from maven-bundle-plugin to bnd-maven-plugin

[Quinn Stevenson (JIRA)]

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

Quinn Stevenson commented on CAMEL-9754:


I've worked through the basics for this, and it looks very promising.

I'm waiting for version 3.2.0 of the bnd-maven-plugin because I need the 
-snapshot=SNAPSHOT functionality to replicated what is currently done by the 
maven-bundle-plugin.

> Convert from maven-bundle-plugin to bnd-maven-plugin
> 
>
> Key: CAMEL-9754
> URL: https://issues.apache.org/jira/browse/CAMEL-9754
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Quinn Stevenson
>
> Currently, the v2.3.7 of the maven-bundle-plugin is used to generate the OSGi 
> Manifests for the Camel libraries.  The project cannot upgrade to a later 
> version of the maven-bundle-plugin because the newer versions break the build.
> The bnd-maven-plugin is maintained by the same group that maintains the BND 
> libraries (which both plugins use internally) expedites updates to the plugin 
> when the underlying libraries change.  Also, the bnd-maven-plugin uses the 
> same BND configuration file format as BND, which eliminates the complex 
> mapping from XML to BND configuration that the maven-bundle-plugin has to 
> deal with.
> The goals are:
>  - change from the maven-bundle-plugin to the bnd-maven-plugin
>  - upgrade the OSGi version
>  - upgrade the default OSGi dependencies in the parent POM



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

[jira] [Created] (CAMEL-9813) Zookeeper route policy requires first message to check if online.

[Jose Luis Pedrosa (JIRA)]

Jose Luis Pedrosa created CAMEL-9813:


 Summary: Zookeeper route policy requires first message to check if 
online.
 Key: CAMEL-9813
 URL: https://issues.apache.org/jira/browse/CAMEL-9813
 Project: Camel
  Issue Type: Bug
  Components: camel-zookeeper
Affects Versions: 2.17.0
 Environment: Java 1.8
wildfly 10.0.0
camel 2.17.0
Reporter: Jose Luis Pedrosa


Hi All

i've been investigaten after I found the same issue as described in the email 
chain 
(http://camel.465427.n5.nabble.com/Zookeeper-Route-Policy-not-respected-on-route-with-sftp-consumer-td5771610.html)

The issue lies in the fact that ZookeeperRoutePolicy (ZRP from now on) waits to 
check if that node is master after the first message have been recived (which 
causes exception in the logs, and of course attempts to process messages).

What it does is simply throw an exception if we are not master... which stops 
the route, sounds like we should not even the start the route in the first 
place if we are not master. 

I've been playing around, trying to implement the first check in the onStart or 
onInit, the problem is that ZRP depends on a internal route injected on the 
policy, I guess that is why the original developer did it in ExchangeBegin 
instead of in start or onInit, to overcome the issue.


{code:java}
   private class ElectoralMonitorRoute extends RouteBuilder {
...
...
from(zep).id("election-route-" + candidateName).sort(body(), 
comparator).process(new Processor() {
@Override
public void process(Exchange e) throws Exception {
@SuppressWarnings("unchecked")
List candidates = 
e.getIn().getMandatoryBody(List.class);
// we cannot use the binary search here and the candidates 
a not sorted in the normal way
/**
 * check if the item at this location starts with this nodes
 * candidate name
 */
int location = 
findCandidateLocationInCandidatesList(candidates, candidateName); 
if (location != -1) {
// set the nodes
masterNode.set(location <= enabledCount);
LOG.debug("This node is number '{}' on the candidate 
list, election is configured for the top '{}'. this node will be {}",
new Object[]{location, enabledCount, 
masterNode.get() ? "enabled" : "disabled"}
);
}
electionComplete.countDown();

notifyElectionWatchers();
}
{code}

which makes a route dependant on another to start, which is hard to solve in a 
clean way.

Also i found that for some routes (my case) it also does not start them 
automatically because they are stopped and not suspended:

{code}
  public static boolean resumeService(Object service) throws Exception {
if (service instanceof SuspendableService) {
SuspendableService ss = (SuspendableService) service;
if (ss.isSuspended()) {
LOG.debug("Resuming service {}", service);
ss.resume();
return true;
} else {
return false;
}
} else {
startService(service);
return true;
}
}
{code}





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

[jira] [Commented] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[JIRA]

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

Thomas Küstermann commented on CAMEL-9808:
--

Is there any documentation that requires ti be updated and I am allowed to 
contribute to?

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Updated] (CAMEL-9791) DeadLetterChannel not triggered on RejectedExecutionException

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9791:
---
Fix Version/s: 2.18.0

> DeadLetterChannel not triggered on RejectedExecutionException
> -
>
> Key: CAMEL-9791
> URL: https://issues.apache.org/jira/browse/CAMEL-9791
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.17.0
>Reporter: Thibaut Robert
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.0
>
> Attachments: ThreadsRejectedExecutionWithDeadLetterTest.java
>
>
> I use a thread processor to implement multi-threading
> I wish that the deadletter endpoint of the route to be called when the pool 
> reject the execution of the task (to save the message on disk)
> However, whatever the rejectedPolicy I choose, the rejected exchange is just 
> dropped because the exchange is marked with routeStop and redeliveryExhausted.
> I think it's correct to not redeliver (we are lacking resources, replaying 
> won't help), but there should at least be a way to handle the failed message 
> somehow.



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

[jira] [Commented] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9808:
---

Github user thokuest closed the pull request at:

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


> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Commented] (CAMEL-9098) Camel Hystrix component

[Bilgin Ibryam (JIRA)]

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

Bilgin Ibryam commented on CAMEL-9098:
--

cool! I'll update the feature then.

> Camel Hystrix component
> ---
>
> Key: CAMEL-9098
> URL: https://issues.apache.org/jira/browse/CAMEL-9098
> Project: Camel
>  Issue Type: New Feature
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
> Fix For: 2.18.0
>
>
> Create a camel-hystrix component with the following features:
> * (/) Capable of wrapping processors.
> * (/) Capable of wrapping static endpoints:
> ** (/) wrapping Endpoint objects.
> ** (/) wrapping URIs.
> * (/) Fluent builders to wrap processors and endpoints.
> * Support building Hystrix endpoints with URIs.
> * (/) Support fallback endpoints and processors.
> * (/) Support response caching, where cache key is calculated by Camel 
> Expressions.
> * (/) Support suppressing exceptions to avoid fallback via 
> HystrixBadRequestException.
> * Request collapsing.
> * (/) HystrixRequestContext propagation via Camel headers, to allow multiple 
> threads to share the HystrixRequestContext.
> * Full support in OSGi (Hystrix, Archaius).
> * Integrate Archaius configuration with Camel property placeholders – if 
> possible – including OSGi Config Admin integration.
> * Integrate with Turbine to enable the nice Hystrix dashboard.
> (/) = done



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

[jira] [Commented] (CAMEL-9812) Camel leaves Kafka consumers running after shutdown

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9812:


Thanks for reporting. Sound like the consumer need to call some stop/shutdown 
on kafka somewhere if its not already doing that, or missing something.

> Camel leaves Kafka consumers running after shutdown
> ---
>
> Key: CAMEL-9812
> URL: https://issues.apache.org/jira/browse/CAMEL-9812
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 2.17.0
> Environment: wildfly 10
> Java 1.8
> Camel: 2.17.0
>Reporter: Jose Luis Pedrosa
>Assignee: Andrea Cosentino
> Attachments: kafkaThreadStack.png
>
>
> After shutting down a camel context, there are still threads running kafka 
> consumers. 
> In the logs after the shutdown I can see:
> {noformat}
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) uptime 25.047 seconds
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) is shutdown in 0.856 seconds
> 14:45:57,494 INFO  
> [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean] 
> (ServerService Thread Pool -- 81) Closing JPA EntityManagerFactory for 
> persistence unit 'default'
> 14:45:57,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) 
> WFLYSRV0028: Stopped deployment ucms-wildfly-container-3.0.1-SNAPSHOT.war 
> (runtime-name: ucms-wildfly-container-3.0.1-SNAPSHOT.war) in 1098ms
> 14:45:57,906 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) 
> WFLYDR0002: Content removed from location 
> /opt/wildfly/standalone/data/content/20/13979a02e4b4ec178461d06c2de59fbf424215/content
> 14:45:57,916 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) 
> WFLYSRV0009: Undeployed "ucms-wildfly-container-3.0.1-SNAPSHOT.war" 
> (runtime-name: "ucms-wildfly-container-3.0.1-SNAPSHOT.war")
> 14:46:24,972 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #0 - KafkaTopic[ucmsControlTopic]) Marking the 
> coordinator 2147483647 dead.
> 14:46:26,467 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #2 - KafkaTopic[TOPIC1]) Marking the coordinator 
> 2147483647 dead.
> {noformat}
> So in theory the context is stopped, but I can see threads running with the 
> polling of the sockets of kafka consumers (see attached immage).
> This deployed in an application server (wilfly in my case), causes a lot of 
> issues, because apps get deployed and undeployed without stopping the  JVM, 
> but threads from previous deployments are left there.
> Please also bear in mind that kafka (9.0.1) throws warning messages due to 
> the fact that un expected config items are thrown to the kafka consumer 
> properties.
> {noformat}
> 14:45:33,840 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.window.factor = 0.8 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration sasl.kerberos.kinit.cmd = 
> /usr/bin/kinit was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.jitter = 0.05 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.keystore.type = JKS 
> was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> ssl.trustmanager.algorithm = PKIX was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.min.time.before.relogin = 6 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.protocol = TLS was 
> supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.enabled.protocols = 
> TLSv1.2,TLSv1.1,TLSv1 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The 

[jira] [Commented] (CAMEL-9098) Camel Hystrix component

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino commented on CAMEL-9098:
-

I can take care of the bundle [~bibryam] [~davsclaus].

I already have to push the Jnats one.

> Camel Hystrix component
> ---
>
> Key: CAMEL-9098
> URL: https://issues.apache.org/jira/browse/CAMEL-9098
> Project: Camel
>  Issue Type: New Feature
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
> Fix For: 2.18.0
>
>
> Create a camel-hystrix component with the following features:
> * (/) Capable of wrapping processors.
> * (/) Capable of wrapping static endpoints:
> ** (/) wrapping Endpoint objects.
> ** (/) wrapping URIs.
> * (/) Fluent builders to wrap processors and endpoints.
> * Support building Hystrix endpoints with URIs.
> * (/) Support fallback endpoints and processors.
> * (/) Support response caching, where cache key is calculated by Camel 
> Expressions.
> * (/) Support suppressing exceptions to avoid fallback via 
> HystrixBadRequestException.
> * Request collapsing.
> * (/) HystrixRequestContext propagation via Camel headers, to allow multiple 
> threads to share the HystrixRequestContext.
> * Full support in OSGi (Hystrix, Archaius).
> * Integrate Archaius configuration with Camel property placeholders – if 
> possible – including OSGi Config Admin integration.
> * Integrate with Turbine to enable the nice Hystrix dashboard.
> (/) = done



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

[jira] [Commented] (CAMEL-9098) Camel Hystrix component

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9098:


Yeah add that to the features so it can install at least.
Then log a SM ticket for that archaius bundle. And until the bundle is released 
we can use the wrap

> Camel Hystrix component
> ---
>
> Key: CAMEL-9098
> URL: https://issues.apache.org/jira/browse/CAMEL-9098
> Project: Camel
>  Issue Type: New Feature
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
> Fix For: 2.18.0
>
>
> Create a camel-hystrix component with the following features:
> * (/) Capable of wrapping processors.
> * (/) Capable of wrapping static endpoints:
> ** (/) wrapping Endpoint objects.
> ** (/) wrapping URIs.
> * (/) Fluent builders to wrap processors and endpoints.
> * Support building Hystrix endpoints with URIs.
> * (/) Support fallback endpoints and processors.
> * (/) Support response caching, where cache key is calculated by Camel 
> Expressions.
> * (/) Support suppressing exceptions to avoid fallback via 
> HystrixBadRequestException.
> * Request collapsing.
> * (/) HystrixRequestContext propagation via Camel headers, to allow multiple 
> threads to share the HystrixRequestContext.
> * Full support in OSGi (Hystrix, Archaius).
> * Integrate Archaius configuration with Camel property placeholders – if 
> possible – including OSGi Config Admin integration.
> * Integrate with Turbine to enable the nice Hystrix dashboard.
> (/) = done



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

[jira] [Resolved] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9808.

Resolution: Fixed
  Assignee: Claus Ibsen

Thanks for the PR

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
>Assignee: Claus Ibsen
> Fix For: 2.17.1, 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Commented] (CAMEL-9098) Camel Hystrix component

[Bilgin Ibryam (JIRA)]

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

Bilgin Ibryam commented on CAMEL-9098:
--

Claus I've updated the version to point to latest SMX bundle, but when I tried 
to run a hystrix demo on [OSGI|https://github.com/bibryam/camel-hystrix-demo] I 
had to install other bundles:

install -s 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-configuration/1.9_2
install -s 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-digester/1.8_4
install -s mvn:org.apache.commons/commons-jexl/2.1.1
install -s 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-jxpath/1.3_1
install -s wrap:mvn:com.netflix.archaius/archaius-core/0.4.1
install -s 
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.hystrix/1.4.23_1


I wonder, do we need another SMX bundle for archaius, or is it enough to add 
those to hystrix feature in Camel?



> Camel Hystrix component
> ---
>
> Key: CAMEL-9098
> URL: https://issues.apache.org/jira/browse/CAMEL-9098
> Project: Camel
>  Issue Type: New Feature
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
> Fix For: 2.18.0
>
>
> Create a camel-hystrix component with the following features:
> * (/) Capable of wrapping processors.
> * (/) Capable of wrapping static endpoints:
> ** (/) wrapping Endpoint objects.
> ** (/) wrapping URIs.
> * (/) Fluent builders to wrap processors and endpoints.
> * Support building Hystrix endpoints with URIs.
> * (/) Support fallback endpoints and processors.
> * (/) Support response caching, where cache key is calculated by Camel 
> Expressions.
> * (/) Support suppressing exceptions to avoid fallback via 
> HystrixBadRequestException.
> * Request collapsing.
> * (/) HystrixRequestContext propagation via Camel headers, to allow multiple 
> threads to share the HystrixRequestContext.
> * Full support in OSGi (Hystrix, Archaius).
> * Integrate Archaius configuration with Camel property placeholders – if 
> possible – including OSGi Config Admin integration.
> * Integrate with Turbine to enable the nice Hystrix dashboard.
> (/) = done



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

[jira] [Assigned] (CAMEL-9812) Camel leaves Kafka consumers running after shutdown

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino reassigned CAMEL-9812:
---

Assignee: Andrea Cosentino

> Camel leaves Kafka consumers running after shutdown
> ---
>
> Key: CAMEL-9812
> URL: https://issues.apache.org/jira/browse/CAMEL-9812
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 2.17.0
> Environment: wildfly 10
> Java 1.8
> Camel: 2.17.0
>Reporter: Jose Luis Pedrosa
>Assignee: Andrea Cosentino
> Attachments: kafkaThreadStack.png
>
>
> After shutting down a camel context, there are still threads running kafka 
> consumers. 
> In the logs after the shutdown I can see:
> {noformat}
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) uptime 25.047 seconds
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) is shutdown in 0.856 seconds
> 14:45:57,494 INFO  
> [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean] 
> (ServerService Thread Pool -- 81) Closing JPA EntityManagerFactory for 
> persistence unit 'default'
> 14:45:57,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) 
> WFLYSRV0028: Stopped deployment ucms-wildfly-container-3.0.1-SNAPSHOT.war 
> (runtime-name: ucms-wildfly-container-3.0.1-SNAPSHOT.war) in 1098ms
> 14:45:57,906 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) 
> WFLYDR0002: Content removed from location 
> /opt/wildfly/standalone/data/content/20/13979a02e4b4ec178461d06c2de59fbf424215/content
> 14:45:57,916 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) 
> WFLYSRV0009: Undeployed "ucms-wildfly-container-3.0.1-SNAPSHOT.war" 
> (runtime-name: "ucms-wildfly-container-3.0.1-SNAPSHOT.war")
> 14:46:24,972 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #0 - KafkaTopic[ucmsControlTopic]) Marking the 
> coordinator 2147483647 dead.
> 14:46:26,467 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #2 - KafkaTopic[TOPIC1]) Marking the coordinator 
> 2147483647 dead.
> {noformat}
> So in theory the context is stopped, but I can see threads running with the 
> polling of the sockets of kafka consumers (see attached immage).
> This deployed in an application server (wilfly in my case), causes a lot of 
> issues, because apps get deployed and undeployed without stopping the  JVM, 
> but threads from previous deployments are left there.
> Please also bear in mind that kafka (9.0.1) throws warning messages due to 
> the fact that un expected config items are thrown to the kafka consumer 
> properties.
> {noformat}
> 14:45:33,840 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.window.factor = 0.8 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration sasl.kerberos.kinit.cmd = 
> /usr/bin/kinit was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.jitter = 0.05 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.keystore.type = JKS 
> was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> ssl.trustmanager.algorithm = PKIX was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.min.time.before.relogin = 6 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.protocol = TLS was 
> supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.enabled.protocols = 
> TLSv1.2,TLSv1.1,TLSv1 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.truststore.type = JKS 
> was supplied but isn't a known config.
> 14:45:33,841 WARN  

[jira] [Updated] (CAMEL-9812) Camel leaves Kafka consumers running after shutdown

[Jose Luis Pedrosa (JIRA)]

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

Jose Luis Pedrosa updated CAMEL-9812:
-
Attachment: kafkaThreadStack.png

> Camel leaves Kafka consumers running after shutdown
> ---
>
> Key: CAMEL-9812
> URL: https://issues.apache.org/jira/browse/CAMEL-9812
> Project: Camel
>  Issue Type: Bug
>  Components: camel-kafka
>Affects Versions: 2.17.0
> Environment: wildfly 10
> Java 1.8
> Camel: 2.17.0
>Reporter: Jose Luis Pedrosa
> Attachments: kafkaThreadStack.png
>
>
> After shutting down a camel context, there are still threads running kafka 
> consumers. 
> In the logs after the shutdown I can see:
> {noformat}
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) uptime 25.047 seconds
> 14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] 
> (ServerService Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: 
> ucms-camel-ctx) is shutdown in 0.856 seconds
> 14:45:57,494 INFO  
> [org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean] 
> (ServerService Thread Pool -- 81) Closing JPA EntityManagerFactory for 
> persistence unit 'default'
> 14:45:57,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) 
> WFLYSRV0028: Stopped deployment ucms-wildfly-container-3.0.1-SNAPSHOT.war 
> (runtime-name: ucms-wildfly-container-3.0.1-SNAPSHOT.war) in 1098ms
> 14:45:57,906 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) 
> WFLYDR0002: Content removed from location 
> /opt/wildfly/standalone/data/content/20/13979a02e4b4ec178461d06c2de59fbf424215/content
> 14:45:57,916 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) 
> WFLYSRV0009: Undeployed "ucms-wildfly-container-3.0.1-SNAPSHOT.war" 
> (runtime-name: "ucms-wildfly-container-3.0.1-SNAPSHOT.war")
> 14:46:24,972 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #0 - KafkaTopic[ucmsControlTopic]) Marking the 
> coordinator 2147483647 dead.
> 14:46:26,467 INFO  
> [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
> (ucms-camel-ctx) thread #2 - KafkaTopic[TOPIC1]) Marking the coordinator 
> 2147483647 dead.
> {noformat}
> So in theory the context is stopped, but I can see threads running with the 
> polling of the sockets of kafka consumers (see attached immage).
> This deployed in an application server (wilfly in my case), causes a lot of 
> issues, because apps get deployed and undeployed without stopping the  JVM, 
> but threads from previous deployments are left there.
> Please also bear in mind that kafka (9.0.1) throws warning messages due to 
> the fact that un expected config items are thrown to the kafka consumer 
> properties.
> {noformat}
> 14:45:33,840 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.window.factor = 0.8 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration sasl.kerberos.kinit.cmd = 
> /usr/bin/kinit was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.ticket.renew.jitter = 0.05 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.keystore.type = JKS 
> was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> ssl.trustmanager.algorithm = PKIX was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration 
> sasl.kerberos.min.time.before.relogin = 6 was supplied but isn't a known 
> config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.protocol = TLS was 
> supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.enabled.protocols = 
> TLSv1.2,TLSv1.1,TLSv1 was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 76) The configuration ssl.truststore.type = JKS 
> was supplied but isn't a known config.
> 14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
> (ServerService Thread Pool -- 

[jira] [Created] (CAMEL-9812) Camel leaves Kafka consumers running after shutdown

[Jose Luis Pedrosa (JIRA)]

Jose Luis Pedrosa created CAMEL-9812:


 Summary: Camel leaves Kafka consumers running after shutdown
 Key: CAMEL-9812
 URL: https://issues.apache.org/jira/browse/CAMEL-9812
 Project: Camel
  Issue Type: Bug
  Components: camel-kafka
Affects Versions: 2.17.0
 Environment: wildfly 10
Java 1.8
Camel: 2.17.0
Reporter: Jose Luis Pedrosa


After shutting down a camel context, there are still threads running kafka 
consumers. 

In the logs after the shutdown I can see:

{noformat}
14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] (ServerService 
Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: ucms-camel-ctx) uptime 
25.047 seconds
14:45:57,455 INFO  [org.apache.camel.spring.SpringCamelContext] (ServerService 
Thread Pool -- 81) Apache Camel 2.17.0 (CamelContext: ucms-camel-ctx) is 
shutdown in 0.856 seconds
14:45:57,494 INFO  
[org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean] 
(ServerService Thread Pool -- 81) Closing JPA EntityManagerFactory for 
persistence unit 'default'
14:45:57,652 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) 
WFLYSRV0028: Stopped deployment ucms-wildfly-container-3.0.1-SNAPSHOT.war 
(runtime-name: ucms-wildfly-container-3.0.1-SNAPSHOT.war) in 1098ms
14:45:57,906 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 2) 
WFLYDR0002: Content removed from location 
/opt/wildfly/standalone/data/content/20/13979a02e4b4ec178461d06c2de59fbf424215/content
14:45:57,916 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) 
WFLYSRV0009: Undeployed "ucms-wildfly-container-3.0.1-SNAPSHOT.war" 
(runtime-name: "ucms-wildfly-container-3.0.1-SNAPSHOT.war")
14:46:24,972 INFO  
[org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
(ucms-camel-ctx) thread #0 - KafkaTopic[ucmsControlTopic]) Marking the 
coordinator 2147483647 dead.
14:46:26,467 INFO  
[org.apache.kafka.clients.consumer.internals.AbstractCoordinator] (Camel 
(ucms-camel-ctx) thread #2 - KafkaTopic[TOPIC1]) Marking the coordinator 
2147483647 dead.
{noformat}

So in theory the context is stopped, but I can see threads running with the 
polling of the sockets of kafka consumers (see attached immage).

This deployed in an application server (wilfly in my case), causes a lot of 
issues, because apps get deployed and undeployed without stopping the  JVM, but 
threads from previous deployments are left there.

Please also bear in mind that kafka (9.0.1) throws warning messages due to the 
fact that un expected config items are thrown to the kafka consumer properties.

{noformat}
14:45:33,840 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration 
sasl.kerberos.ticket.renew.window.factor = 0.8 was supplied but isn't a known 
config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration sasl.kerberos.kinit.cmd = 
/usr/bin/kinit was supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration 
sasl.kerberos.ticket.renew.jitter = 0.05 was supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.keystore.type = JKS was 
supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.trustmanager.algorithm 
= PKIX was supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration 
sasl.kerberos.min.time.before.relogin = 6 was supplied but isn't a known 
config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.protocol = TLS was 
supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.enabled.protocols = 
TLSv1.2,TLSv1.1,TLSv1 was supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.truststore.type = JKS 
was supplied but isn't a known config.
14:45:33,841 WARN  [org.apache.kafka.clients.consumer.ConsumerConfig] 
(ServerService Thread Pool -- 76) The configuration ssl.keymanager.algorithm = 
SunX509 was supplied but isn't a known config.
{noformat}

Thanks!






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

[jira] [Commented] (CAMEL-9789) CamelContext.getEndpoint should not start endpoint if Camel is starting up

[Hubertus Willuhn (JIRA)]

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

Hubertus Willuhn commented on CAMEL-9789:
-

After upgrading to Camel 1.17.0 my Routes are crashing with stacktraces like 
the following (seems to be related to this issue, my own packages are masked 
with **):

14:32:31 | [main] CamelApp| ERROR | Camel 
App crashed, Reason: Error creating bean with name 'camelContext' defined in 
class **.config.CamelConfig: Invocation of init method failed; nested exception 
is java.lang.IllegalArgumentException: Cannot add component as its already 
previously added: properties
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'camelContext' defined in class **.config.CamelConfig: Invocation of 
init method failed; nested exception is java.lang.IllegalArgumentException: 
Cannot add component as its already previously added: properties
Related cause: 
org.springframework.beans.factory.BeanCurrentlyInCreationException: Error 
creating bean with name 'camelContext': Requested bean is currently in 
creation: Is there an unresolvable circular reference?
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:306)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:302)
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:772)
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:839)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:538)
at 
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:689)
at 
org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
at **.CamelApp.main(CamelApp.java:67)
Caused by: java.lang.IllegalArgumentException: Cannot add component as its 
already previously added: properties
at 
org.apache.camel.impl.DefaultCamelContext.addComponent(DefaultCamelContext.java:370)
at 
org.apache.camel.util.CamelContextHelper.lookupPropertiesComponent(CamelContextHelper.java:578)
at 
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3003)
at 
org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
at 
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2848)
  t 
org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2844)
at 
org.apache.camel.impl.DefaultCamelContext.doWithDefinedClassLoader(DefaultCamelContext.java:2867)
at 
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:2844)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at 
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:2813)
at 
org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:270)
at 
org.apache.camel.spring.SpringCamelContext.afterPropertiesSet(SpringCamelContext.java:122)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
... 12 more  
Related cause:   
org.springframework.beans.factory.BeanCurrentlyInCreationException: Error 
creating bean with name 'camelContext': Requested bean is currently in 
creation: Is there an unresolvable circular reference?
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:347)
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at 

[jira] [Updated] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9808:
---
Fix Version/s: 2.17.1

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
> Fix For: 2.17.1, 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Commented] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9808:


Thanks I put some comments in the PR as there is some code formatting changes 
needed.

You can read about building with checkstyle here
http://camel.apache.org/building

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
> Fix For: 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Updated] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9808:
---
Fix Version/s: 2.18.0

> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
> Fix For: 2.18.0
>
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Resolved] (CAMEL-9807) Blocking of CXF consumer endpoint by http GET request

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9807.

Resolution: Fixed
  Assignee: Claus Ibsen

Thanks for reporting and the patch. I modified it a bit and added a 2nd test 
that does a bit more testing.

> Blocking of CXF consumer endpoint by http GET request
> -
>
> Key: CAMEL-9807
> URL: https://issues.apache.org/jira/browse/CAMEL-9807
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.2
>Reporter: Joerg Kessler
>Assignee: Claus Ibsen
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
> Attachments: CXFTypeConverter.patch
>
>
> Hi,
> by chance we found a problem that can create a security risk. The scenario is 
> a CXF WS consumer endpoint configured without WSDL and right after that a 
> step, e.g. a setHeader that uses an XPath to access the CXF payload. When you 
> now create a http GET request on the endpoint (normally it should be POST) 
> then the error No type converter available to convert from type: 
> org.apache.camel.component.cxf.converter.CachedCxfPayload to the required 
> type: javax.xml.transform.sax.SAXSource with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@45812dad
> is thrown.
> First of all it is surprising that CXF accepts the request. Second a type 
> conversion like that is possible. The reason for this error message is within 
> the type converter coding. The converter returns a null object for the not 
> existing payload of the GET request but this is interpreted as there is no 
> type converter available. One could say that this is just a bad error message 
> but more over the type converter is now kind of black-listed internally. That 
> means the next calls being correct or wrong will not look for a type 
> converter but return immedeately the above error. That means the endpoint is 
> blocked until the scenario is restarted. This seems to be more efficient than 
> a DOS attack (but of course one has to have access rights). I provide a 
> simple patch that raises a runtime exception in the CXF type converter when 
> there is no payload. I am not 100% sure whether this is the best way to fix 
> it. Maybe GET requests should be blocked already in CXF. I also could imagine 
> that somethin like that is also possible in other components. 
> We use Camel 2.16.2 and I tested it in CXF 2.16.3 and it is not fixed.  



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

[jira] [Commented] (CAMEL-9798) camel-cdi - Add support for injecting default ProducerTemplate

[Antonin Stefanutti (JIRA)]

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

Antonin Stefanutti commented on CAMEL-9798:
---

[~davsclaus] I've just fixed it (that was in my todo list for a long time :)).

For the INFO messages, unfortunately the only way to get rid of it is to drop 
support for CDI 1.0 (I spare you the details). For the time being, I'd be 
inclined to keep support for it as quite some users are still stuck with that 
version.

That being said, I've logged 
[WELD-2130|https://issues.jboss.org/browse/WELD-2130] to see what can be done 
at the Weld level.


> camel-cdi - Add support for injecting default ProducerTemplate
> --
>
> Key: CAMEL-9798
> URL: https://issues.apache.org/jira/browse/CAMEL-9798
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.17.0
>Reporter: Claus Ibsen
>Assignee: Antonin Stefanutti
> Fix For: 2.17.1, 2.18.0
>
>
> We should be able to inject a default producer template using
> {code}
> @Inject
> private ProducerTemplate template;
> {code}
> Currently that does not work and you get an error (see below)
> But if you setup a default endpoint with @Uri it works
> {code}
> @Inject @Uri("file:target/inbox")
> private ProducerTemplate template;
> {code}
> The error you get
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type ProducerTemplate with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> camelinaction.FirstTest.template
>   at camelinaction.FirstTest.template(FirstTest.java:0)
> WELD-001475: The following beans match by type, but none have matching 
> qualifiers:
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)],
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)]
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>   at 
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>   at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>   at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> The same thing for ConsumerTemplate which should also be injectable.



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

[jira] [Resolved] (CAMEL-9811) camel-cdi - Add support for consumer template injection

[Antonin Stefanutti (JIRA)]

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

Antonin Stefanutti resolved CAMEL-9811.
---
Resolution: Fixed

> camel-cdi - Add support for consumer template injection
> ---
>
> Key: CAMEL-9811
> URL: https://issues.apache.org/jira/browse/CAMEL-9811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Reporter: Antonin Stefanutti
>Assignee: Antonin Stefanutti
> Fix For: 2.17.1, 2.18.0
>
>




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

[jira] [Resolved] (CAMEL-9798) camel-cdi - Add support for injecting default ProducerTemplate

[Antonin Stefanutti (JIRA)]

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

Antonin Stefanutti resolved CAMEL-9798.
---
Resolution: Fixed

> camel-cdi - Add support for injecting default ProducerTemplate
> --
>
> Key: CAMEL-9798
> URL: https://issues.apache.org/jira/browse/CAMEL-9798
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.17.0
>Reporter: Claus Ibsen
>Assignee: Antonin Stefanutti
> Fix For: 2.17.1, 2.18.0
>
>
> We should be able to inject a default producer template using
> {code}
> @Inject
> private ProducerTemplate template;
> {code}
> Currently that does not work and you get an error (see below)
> But if you setup a default endpoint with @Uri it works
> {code}
> @Inject @Uri("file:target/inbox")
> private ProducerTemplate template;
> {code}
> The error you get
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type ProducerTemplate with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> camelinaction.FirstTest.template
>   at camelinaction.FirstTest.template(FirstTest.java:0)
> WELD-001475: The following beans match by type, but none have matching 
> qualifiers:
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)],
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)]
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>   at 
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>   at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>   at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> The same thing for ConsumerTemplate which should also be injectable.



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

[jira] [Updated] (CAMEL-9811) camel-cdi - Add support for consumer template injection

[Antonin Stefanutti (JIRA)]

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

Antonin Stefanutti updated CAMEL-9811:
--
Fix Version/s: 2.18.0
   2.17.1

> camel-cdi - Add support for consumer template injection
> ---
>
> Key: CAMEL-9811
> URL: https://issues.apache.org/jira/browse/CAMEL-9811
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Reporter: Antonin Stefanutti
>Assignee: Antonin Stefanutti
> Fix For: 2.17.1, 2.18.0
>
>




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

[jira] [Updated] (CAMEL-9798) camel-cdi - Add support for injecting default ProducerTemplate

[Antonin Stefanutti (JIRA)]

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

Antonin Stefanutti updated CAMEL-9798:
--
Fix Version/s: 2.18.0
   2.17.1

> camel-cdi - Add support for injecting default ProducerTemplate
> --
>
> Key: CAMEL-9798
> URL: https://issues.apache.org/jira/browse/CAMEL-9798
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.17.0
>Reporter: Claus Ibsen
>Assignee: Antonin Stefanutti
> Fix For: 2.17.1, 2.18.0
>
>
> We should be able to inject a default producer template using
> {code}
> @Inject
> private ProducerTemplate template;
> {code}
> Currently that does not work and you get an error (see below)
> But if you setup a default endpoint with @Uri it works
> {code}
> @Inject @Uri("file:target/inbox")
> private ProducerTemplate template;
> {code}
> The error you get
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type ProducerTemplate with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> camelinaction.FirstTest.template
>   at camelinaction.FirstTest.template(FirstTest.java:0)
> WELD-001475: The following beans match by type, but none have matching 
> qualifiers:
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)],
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)]
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>   at 
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>   at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>   at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> The same thing for ConsumerTemplate which should also be injectable.



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

[jira] [Updated] (CAMEL-9807) Blocking of CXF consumer endpoint by http GET request

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9807:
---
Priority: Major  (was: Critical)

> Blocking of CXF consumer endpoint by http GET request
> -
>
> Key: CAMEL-9807
> URL: https://issues.apache.org/jira/browse/CAMEL-9807
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.2
>Reporter: Joerg Kessler
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
> Attachments: CXFTypeConverter.patch
>
>
> Hi,
> by chance we found a problem that can create a security risk. The scenario is 
> a CXF WS consumer endpoint configured without WSDL and right after that a 
> step, e.g. a setHeader that uses an XPath to access the CXF payload. When you 
> now create a http GET request on the endpoint (normally it should be POST) 
> then the error No type converter available to convert from type: 
> org.apache.camel.component.cxf.converter.CachedCxfPayload to the required 
> type: javax.xml.transform.sax.SAXSource with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@45812dad
> is thrown.
> First of all it is surprising that CXF accepts the request. Second a type 
> conversion like that is possible. The reason for this error message is within 
> the type converter coding. The converter returns a null object for the not 
> existing payload of the GET request but this is interpreted as there is no 
> type converter available. One could say that this is just a bad error message 
> but more over the type converter is now kind of black-listed internally. That 
> means the next calls being correct or wrong will not look for a type 
> converter but return immedeately the above error. That means the endpoint is 
> blocked until the scenario is restarted. This seems to be more efficient than 
> a DOS attack (but of course one has to have access rights). I provide a 
> simple patch that raises a runtime exception in the CXF type converter when 
> there is no payload. I am not 100% sure whether this is the best way to fix 
> it. Maybe GET requests should be blocked already in CXF. I also could imagine 
> that somethin like that is also possible in other components. 
> We use Camel 2.16.2 and I tested it in CXF 2.16.3 and it is not fixed.  



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

[jira] [Updated] (CAMEL-9807) Blocking of CXF consumer endpoint by http GET request

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9807:
---
Fix Version/s: 2.18.0
   2.17.1
   2.16.4

> Blocking of CXF consumer endpoint by http GET request
> -
>
> Key: CAMEL-9807
> URL: https://issues.apache.org/jira/browse/CAMEL-9807
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.2
>Reporter: Joerg Kessler
>Priority: Critical
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
> Attachments: CXFTypeConverter.patch
>
>
> Hi,
> by chance we found a problem that can create a security risk. The scenario is 
> a CXF WS consumer endpoint configured without WSDL and right after that a 
> step, e.g. a setHeader that uses an XPath to access the CXF payload. When you 
> now create a http GET request on the endpoint (normally it should be POST) 
> then the error No type converter available to convert from type: 
> org.apache.camel.component.cxf.converter.CachedCxfPayload to the required 
> type: javax.xml.transform.sax.SAXSource with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@45812dad
> is thrown.
> First of all it is surprising that CXF accepts the request. Second a type 
> conversion like that is possible. The reason for this error message is within 
> the type converter coding. The converter returns a null object for the not 
> existing payload of the GET request but this is interpreted as there is no 
> type converter available. One could say that this is just a bad error message 
> but more over the type converter is now kind of black-listed internally. That 
> means the next calls being correct or wrong will not look for a type 
> converter but return immedeately the above error. That means the endpoint is 
> blocked until the scenario is restarted. This seems to be more efficient than 
> a DOS attack (but of course one has to have access rights). I provide a 
> simple patch that raises a runtime exception in the CXF type converter when 
> there is no payload. I am not 100% sure whether this is the best way to fix 
> it. Maybe GET requests should be blocked already in CXF. I also could imagine 
> that somethin like that is also possible in other components. 
> We use Camel 2.16.2 and I tested it in CXF 2.16.3 and it is not fixed.  



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

[jira] [Resolved] (CAMEL-9806) Add camel-IronMQ Karaf feature

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino resolved CAMEL-9806.
-
Resolution: Fixed

> Add camel-IronMQ Karaf feature
> --
>
> Key: CAMEL-9806
> URL: https://issues.apache.org/jira/browse/CAMEL-9806
> Project: Camel
>  Issue Type: Task
>  Components: camel-ironmq, karaf
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.17.1, 2.18.0
>
>
> The IronMQ bundle has been released. We can add the Karaf feature for this 
> component.



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

[jira] [Created] (CAMEL-9811) camel-cdi - Add support for consumer template injection

[Antonin Stefanutti (JIRA)]

Antonin Stefanutti created CAMEL-9811:
-

 Summary: camel-cdi - Add support for consumer template injection
 Key: CAMEL-9811
 URL: https://issues.apache.org/jira/browse/CAMEL-9811
 Project: Camel
  Issue Type: Improvement
  Components: camel-cdi
Reporter: Antonin Stefanutti
Assignee: Antonin Stefanutti






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

[jira] [Created] (CAMEL-9810) Cleanup remote branches

[Claus Ibsen (JIRA)]

Claus Ibsen created CAMEL-9810:
--

 Summary: Cleanup remote branches
 Key: CAMEL-9810
 URL: https://issues.apache.org/jira/browse/CAMEL-9810
 Project: Camel
  Issue Type: Task
  Components: build system
Reporter: Claus Ibsen


To not forget about this
http://camel.465427.n5.nabble.com/Cleanup-remote-branches-tp5780146.html



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

[jira] [Resolved] (CAMEL-9809) Can't set nonProxyHosts in camel context

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9809.

Resolution: Invalid
  Assignee: Claus Ibsen

Use the user mailing list or user forum to get help with Camel

> Can't set nonProxyHosts in camel context 
> -
>
> Key: CAMEL-9809
> URL: https://issues.apache.org/jira/browse/CAMEL-9809
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.14.4
>Reporter: Rhushikesh Ganesh Apte
>Assignee: Claus Ibsen
>
> I am trying to use proxy setting in my apche camel context. Now for few of my 
> internal network http endpoints I want to exclude these proxy settings but I 
> am not able to.



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

[jira] [Commented] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9808:
---

GitHub user thokuest opened a pull request:

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

CAMEL-9808: SFTP: Enable configuration of bulk requests

This pull request makes it possible to configure the number of bulk 
requests issued by JSch. Increasing the number of bulk requests may slightly 
improve transfer speed at the cost of memory usage.

Usage:

sftp://nosuchhost/workingdir?bulkRequests=64;...

See [CAMEL-9808](https://issues.apache.org/jira/browse/CAMEL-9808) for 
details.

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

$ git pull https://github.com/thokuest/camel CAMEL-9808

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

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


commit f563517ddbc8b3569b98deafaad8936b129140b3
Author: Thomas Küstermann 
Date:   2016-04-04T10:24:30Z

Merge remote-tracking branch 'refs/remotes/apache/master'

commit 1e19ed04a93bc904a64974bbd2e536379f667003
Author: Thomas Küstermann 
Date:   2016-04-04T11:05:36Z

CAMEL-9808: Enable configuration of bulk requests




> SFTP: Enable configuration of bulk requests
> ---
>
> Key: CAMEL-9808
> URL: https://issues.apache.org/jira/browse/CAMEL-9808
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-ftp
>Reporter: Thomas Küstermann
>
> JSch uses multiple requests to pull files from / push files to a SFTP server. 
> The number of bulk requests can be configured via 
> {{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
> increasing this value may slightly improve file transfer speed at the cost of 
> memory usage.
> The configuration option should be made available in Camel.
> h4. Background
> I came across an issue with a specific SFTP server product. I tracked this 
> issue down to the way bulk requests are sent to the SFTP server. To cut a 
> long story short ([details 
> here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
>  setting the number of bulk requests to 1 solves the problem, so it would be 
> nice to have this option available via Camel.



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

[jira] [Created] (CAMEL-9808) SFTP: Enable configuration of bulk requests

[JIRA]

Thomas Küstermann created CAMEL-9808:


 Summary: SFTP: Enable configuration of bulk requests
 Key: CAMEL-9808
 URL: https://issues.apache.org/jira/browse/CAMEL-9808
 Project: Camel
  Issue Type: Improvement
  Components: camel-ftp
Reporter: Thomas Küstermann


JSch uses multiple requests to pull files from / push files to a SFTP server. 
The number of bulk requests can be configured via 
{{ChannelSftp#setBulkRequests(int)}}. The API documentation states that 
increasing this value may slightly improve file transfer speed at the cost of 
memory usage.

The configuration option should be made available in Camel.

h4. Background

I came across an issue with a specific SFTP server product. I tracked this 
issue down to the way bulk requests are sent to the SFTP server. To cut a long 
story short ([details 
here|https://sourceforge.net/p/jsch/mailman/jsch-users/thread/AM4PR10MB01646456AD2C94D911BDA763E1880%40AM4PR10MB0164.EURPRD10.PROD.OUTLOOK.COM/#msg34933773])
 setting the number of bulk requests to 1 solves the problem, so it would be 
nice to have this option available via Camel.



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

[jira] [Updated] (CAMEL-9807) Blocking of CXF consumer endpoint by http GET request

[Joerg Kessler (JIRA)]

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

Joerg Kessler updated CAMEL-9807:
-
Attachment: CXFTypeConverter.patch

> Blocking of CXF consumer endpoint by http GET request
> -
>
> Key: CAMEL-9807
> URL: https://issues.apache.org/jira/browse/CAMEL-9807
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.16.2
>Reporter: Joerg Kessler
>Priority: Critical
> Attachments: CXFTypeConverter.patch
>
>
> Hi,
> by chance we found a problem that can create a security risk. The scenario is 
> a CXF WS consumer endpoint configured without WSDL and right after that a 
> step, e.g. a setHeader that uses an XPath to access the CXF payload. When you 
> now create a http GET request on the endpoint (normally it should be POST) 
> then the error No type converter available to convert from type: 
> org.apache.camel.component.cxf.converter.CachedCxfPayload to the required 
> type: javax.xml.transform.sax.SAXSource with value 
> org.apache.camel.component.cxf.converter.CachedCxfPayload@45812dad
> is thrown.
> First of all it is surprising that CXF accepts the request. Second a type 
> conversion like that is possible. The reason for this error message is within 
> the type converter coding. The converter returns a null object for the not 
> existing payload of the GET request but this is interpreted as there is no 
> type converter available. One could say that this is just a bad error message 
> but more over the type converter is now kind of black-listed internally. That 
> means the next calls being correct or wrong will not look for a type 
> converter but return immedeately the above error. That means the endpoint is 
> blocked until the scenario is restarted. This seems to be more efficient than 
> a DOS attack (but of course one has to have access rights). I provide a 
> simple patch that raises a runtime exception in the CXF type converter when 
> there is no payload. I am not 100% sure whether this is the best way to fix 
> it. Maybe GET requests should be blocked already in CXF. I also could imagine 
> that somethin like that is also possible in other components. 
> We use Camel 2.16.2 and I tested it in CXF 2.16.3 and it is not fixed.  



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

[jira] [Created] (CAMEL-9806) Add camel-ironmq Karaf feature

[Andrea Cosentino (JIRA)]

Andrea Cosentino created CAMEL-9806:
---

 Summary: Add camel-ironmq Karaf feature
 Key: CAMEL-9806
 URL: https://issues.apache.org/jira/browse/CAMEL-9806
 Project: Camel
  Issue Type: Task
  Components: camel-ironmq, karaf
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Priority: Minor
 Fix For: 2.17.1, 2.18.0


The IronMQ bundle has been released. We can add the Karaf feature for this 
component.



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

[jira] [Work started] (CAMEL-9798) camel-cdi - Add support for injecting default ProducerTemplate

[Antonin Stefanutti (JIRA)]

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

Work on CAMEL-9798 started by Antonin Stefanutti.
-
> camel-cdi - Add support for injecting default ProducerTemplate
> --
>
> Key: CAMEL-9798
> URL: https://issues.apache.org/jira/browse/CAMEL-9798
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-cdi
>Affects Versions: 2.17.0
>Reporter: Claus Ibsen
>Assignee: Antonin Stefanutti
>
> We should be able to inject a default producer template using
> {code}
> @Inject
> private ProducerTemplate template;
> {code}
> Currently that does not work and you get an error (see below)
> But if you setup a default endpoint with @Uri it works
> {code}
> @Inject @Uri("file:target/inbox")
> private ProducerTemplate template;
> {code}
> The error you get
> {code}
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied 
> dependencies for type ProducerTemplate with qualifiers @Default
>   at injection point [BackedAnnotatedField] @Inject private 
> camelinaction.FirstTest.template
>   at camelinaction.FirstTest.template(FirstTest.java:0)
> WELD-001475: The following beans match by type, but none have matching 
> qualifiers:
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)],
>   - Producer Method [ProducerTemplate] with qualifiers [@Excluded @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @Excluded private static 
> org.apache.camel.cdi.CdiCamelFactory.producerTemplate(InjectionPoint, @Any 
> Instance, CdiCamelExtension)]
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
>   at 
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
>   at 
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
>   at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
>   at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
>   at 
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
>   at 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> The same thing for ConsumerTemplate which should also be injectable.



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

[jira] [Commented] (CAMEL-9549) camel-schematron - More fine grained error messages when compiling the schema

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-9549:
---

Github user asfgit closed the pull request at:

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


> camel-schematron - More fine grained error messages when compiling the schema
> -
>
> Key: CAMEL-9549
> URL: https://issues.apache.org/jira/browse/CAMEL-9549
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-schematron
>Affects Versions: 2.15.3
>Reporter: Johan Mörén
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
>
> When pre-compiling the schematron rules files. Errors such as 
> xslt-compilation errors, includes not found etc. are always caught and 
> presented with an error message saying incorrectly that the schematron rules 
> file could not be found. 
> In the two errors above the file has been found but compilation of it has 
> failed. 
> To make troubleshooting easier i think that a more fine grained error 
> handling could provide the user with a better view of what the underlying 
> error really is. 



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

[jira] [Resolved] (CAMEL-9549) camel-schematron - More fine grained error messages when compiling the schema

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9549.

Resolution: Fixed
  Assignee: Claus Ibsen

> camel-schematron - More fine grained error messages when compiling the schema
> -
>
> Key: CAMEL-9549
> URL: https://issues.apache.org/jira/browse/CAMEL-9549
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-schematron
>Affects Versions: 2.15.3
>Reporter: Johan Mörén
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
>
> When pre-compiling the schematron rules files. Errors such as 
> xslt-compilation errors, includes not found etc. are always caught and 
> presented with an error message saying incorrectly that the schematron rules 
> file could not be found. 
> In the two errors above the file has been found but compilation of it has 
> failed. 
> To make troubleshooting easier i think that a more fine grained error 
> handling could provide the user with a better view of what the underlying 
> error really is. 



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

[jira] [Updated] (CAMEL-9805) camel-sql - body not copied from in to out when useing outputHeader and outputType=SelectOne when sql doesn't return a result

[Thomas Bender (JIRA)]

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

Thomas Bender updated CAMEL-9805:
-
Attachment: db-camel-schema.sql
db-camel-data.sql
CamelSqlComponentTest.java

Attached a testcase.

> camel-sql - body not copied from in to out when useing outputHeader and 
> outputType=SelectOne when sql doesn't return a result
> -
>
> Key: CAMEL-9805
> URL: https://issues.apache.org/jira/browse/CAMEL-9805
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.17.0
>Reporter: Thomas Bender
> Attachments: CamelSqlComponentTest.java, db-camel-data.sql, 
> db-camel-schema.sql
>
>
> When using the options outputHeader and outputType=SelectOne the body of the 
> Exchange is not copied from in to out when the select returns no data..
> Probably root is line 175-185 of SqlProducer.java that is missing an else for 
> the above mentioned case.
> {code}
> if (data != null) { // <--- Missing the else
> // for noop=true we still want to enrich with the row count header
>   if (getEndpoint().isNoop()) {
> exchange.getOut().setBody(exchange.getIn().getBody());
>   } else if (getEndpoint().getOutputHeader() != null) {
> exchange.getOut().setBody(exchange.getIn().getBody());
> exchange.getOut().setHeader(getEndpoint().getOutputHeader(), data);
>   } else {
> exchange.getOut().setBody(data); 
>   }
>   exchange.getOut().setHeader(SqlConstants.SQL_ROW_COUNT, 1);
> }
> {code}
> following could be added (untested)
> {code}
> else { // if data == null
> if (getEndpoint().isNoop()) {
> 
> exchange.getOut().setBody(exchange.getIn().getBody());
> } else if 
> (getEndpoint().getOutputHeader() != null) {
> 
> exchange.getOut().setBody(exchange.getIn().getBody());
> }
>  exchange.getOut().setHeader(SqlConstants.SQL_ROW_COUNT, 0);
> }
> {code}



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

[jira] [Updated] (CAMEL-9549) camel-schematron - More fine grained error messages when compiling the schema

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9549:
---
Fix Version/s: 2.16.4

> camel-schematron - More fine grained error messages when compiling the schema
> -
>
> Key: CAMEL-9549
> URL: https://issues.apache.org/jira/browse/CAMEL-9549
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-schematron
>Affects Versions: 2.15.3
>Reporter: Johan Mörén
>Priority: Minor
> Fix For: 2.16.4, 2.17.1, 2.18.0
>
>
> When pre-compiling the schematron rules files. Errors such as 
> xslt-compilation errors, includes not found etc. are always caught and 
> presented with an error message saying incorrectly that the schematron rules 
> file could not be found. 
> In the two errors above the file has been found but compilation of it has 
> failed. 
> To make troubleshooting easier i think that a more fine grained error 
> handling could provide the user with a better view of what the underlying 
> error really is. 



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

[jira] [Updated] (CAMEL-9549) camel-schematron - More fine grained error messages when compiling the schema

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-9549:
---
Fix Version/s: 2.17.1
   2.18.0

> camel-schematron - More fine grained error messages when compiling the schema
> -
>
> Key: CAMEL-9549
> URL: https://issues.apache.org/jira/browse/CAMEL-9549
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-schematron
>Affects Versions: 2.15.3
>Reporter: Johan Mörén
>Priority: Minor
> Fix For: 2.18.0, 2.17.1
>
>
> When pre-compiling the schematron rules files. Errors such as 
> xslt-compilation errors, includes not found etc. are always caught and 
> presented with an error message saying incorrectly that the schematron rules 
> file could not be found. 
> In the two errors above the file has been found but compilation of it has 
> failed. 
> To make troubleshooting easier i think that a more fine grained error 
> handling could provide the user with a better view of what the underlying 
> error really is. 



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

[jira] [Resolved] (CAMEL-9804) XMPP chat responding not woring

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9804.

Resolution: Invalid
  Assignee: Claus Ibsen

Please use the user mailing list / user forum to get help / ask questions first
http://camel.apache.org/mailing-lists.html
http://camel.apache.org/discussion-forums.html

> XMPP chat responding not woring
> ---
>
> Key: CAMEL-9804
> URL: https://issues.apache.org/jira/browse/CAMEL-9804
> Project: Camel
>  Issue Type: Bug
>  Components: camel-xmpp
>Affects Versions: 2.17.0
> Environment: jdk1.8.0_65
>Reporter: martin scharm
>Assignee: Claus Ibsen
>
> I tried to implement a simple XMPP bot, but reading and responding to the 
> same XMPP chat seems to fail: The bot sends the message to itself.
> The endpoint is created like the following:
> {code:java}
> String
> userA = "bot",
> userB = "human",
> server = "SERVER",
> port = "5222",
> passwordA = "secret";
> final String chatEndpoint =
>   String.format("xmpp://%s@%s:%s/%s@%s?password=%s",
>   userA, server, port,
>   userB, server, passwordA);
> {code}
> which produces an endpoint such as 
> {{xmpp://bot@SERVER:5222/human@SERVER?password=secret}}, so the {{bot}} 
> authenticates with {{SERVER}} and it will talk to {{human@SERVER}}.
> The bot is able to read from XMPP and dump the messages to std::out:
> {code:java}
> from(chatEndpoint)
> .to("stream:out");
> {code}
> And the bot is able to send XMPP messages:
> {code:java}
> from("timer://foo?fixedRate=true=1000")
> .setBody(constant("test"))
> .to(chatEndpoint); 
> {code}
> So far, I'm really impressed :)
> However, simply responding the human's message fails:
> {code:java}
> from(chatEndpoint)
> .to(chatEndpoint);
> {code}
> My XMPP server (prosody) shows me, that the bot sends the messages to itself:
> {code:java}
> debug   Received[c2s]:  from='bot@SERVER/Camel'>
> {code}
> But I have no idea why.. Am I doing something wrong?
> I tried adding {{=human@SERVER}} to the {{chatEndpoint}} which 
> doesn't solve the issue. I also tried to create two separate chat endpoints 
> with different resource names, but that didn't work either. :(



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