[jira] [Commented] (CAMEL-9502) karaf - Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato commented on CAMEL-9502:
---

I'll check if CAMEL-10914 indeed fixes this issue.

> karaf - Re-installing bundle using camel-cxf throws 
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws 
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN  | pache.cxf.osgi]) | MBeanContainer   
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 |   | bean: 
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException: 
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
>   at 
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
>   at 
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:784)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> 

[jira] [Updated] (CAMEL-10918) JMS 2.0 shared subscriptions

[Ryan Yeats (JIRA)]

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

Ryan Yeats updated CAMEL-10918:
---
Description: 
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 

Here is the changeset:
https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6.patch

  was:
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 

Here is the changeset:
https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6


> JMS 2.0 shared subscriptions
> 
>
> Key: CAMEL-10918
> URL: https://issues.apache.org/jira/browse/CAMEL-10918
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-sjms
>Reporter: Ryan Yeats
>Priority: Minor
>
> This is presumptions of me and I apologize for that and will understand if 
> this is closed outright but I was going to fork camel-sjms and add support 
> for some JMS 2.0 for my own uses and during testing found out that it was 
> still backwards compatible and figured I would contribute it back if you guys 
> found it worth maintaining.
> Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
> NoSuchMethodException as expected but everything else seemed to work. Also 
> tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 
> Here is the changeset:
> https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6.patch



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10918) JMS 2.0 shared subscriptions

[Ryan Yeats (JIRA)]

Ryan Yeats created CAMEL-10918:
--

 Summary: JMS 2.0 shared subscriptions
 Key: CAMEL-10918
 URL: https://issues.apache.org/jira/browse/CAMEL-10918
 Project: Camel
  Issue Type: New Feature
  Components: camel-sjms
Reporter: Ryan Yeats
Priority: Minor


This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato reopened CAMEL-10914:


Thanks [~njiang] for the good catch. I'll send another pull req soon.

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10918) JMS 2.0 shared subscriptions

[Ryan Yeats (JIRA)]

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

Ryan Yeats updated CAMEL-10918:
---
Description: 
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 

https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6

  was:
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 


> JMS 2.0 shared subscriptions
> 
>
> Key: CAMEL-10918
> URL: https://issues.apache.org/jira/browse/CAMEL-10918
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-sjms
>Reporter: Ryan Yeats
>Priority: Minor
>
> This is presumptions of me and I apologize for that and will understand if 
> this is closed outright but I was going to fork camel-sjms and add support 
> for some JMS 2.0 for my own uses and during testing found out that it was 
> still backwards compatible and figured I would contribute it back if you guys 
> found it worth maintaining.
> Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
> NoSuchMethodException as expected but everything else seemed to work. Also 
> tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 
> https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10918) JMS 2.0 shared subscriptions

[Ryan Yeats (JIRA)]

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

Ryan Yeats updated CAMEL-10918:
---
Description: 
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 

Here is the changeset:
https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6

  was:
This is presumptions of me and I apologize for that and will understand if this 
is closed outright but I was going to fork camel-sjms and add support for some 
JMS 2.0 for my own uses and during testing found out that it was still 
backwards compatible and figured I would contribute it back if you guys found 
it worth maintaining.

Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
NoSuchMethodException as expected but everything else seemed to work. Also 
tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 

https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6


> JMS 2.0 shared subscriptions
> 
>
> Key: CAMEL-10918
> URL: https://issues.apache.org/jira/browse/CAMEL-10918
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-sjms
>Reporter: Ryan Yeats
>Priority: Minor
>
> This is presumptions of me and I apologize for that and will understand if 
> this is closed outright but I was going to fork camel-sjms and add support 
> for some JMS 2.0 for my own uses and during testing found out that it was 
> still backwards compatible and figured I would contribute it back if you guys 
> found it worth maintaining.
> Tested this on karaf 4.10 with activemq 5.14.3 shared subscriptions caused a 
> NoSuchMethodException as expected but everything else seemed to work. Also 
> tested on karaf 4.10 with artemis 1.5.1 shared subscriptions worked. 
> Here is the changeset:
> https://github.com/ryeats/camel/commit/80f875572ffd2a16ec24d9302479201dc9b188f6



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10914:


GitHub user tadayosi opened a pull request:

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

CAMEL-10914: Apply the same fix as CxfConsumer to CxfRsConsumer

Follow-up fix to: https://issues.apache.org/jira/browse/CAMEL-10914

@WillemJiang @oscerd @davsclaus Can anyone merge this too, please?

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

$ git pull https://github.com/tadayosi/camel CAMEL-10914_2

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

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


commit d6330e34f702ee619f5a6ac579f54314e278a440
Author: Tadayoshi Sato 
Date:   2017-03-02T01:31:57Z

CAMEL-10914: Apply the same fix as CxfConsumer to CxfRsConsumer




> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato commented on CAMEL-10914:


Great! Thanks [~davsclaus] and [~ancosen].

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Willem Jiang (JIRA)]

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

Willem Jiang commented on CAMEL-10914:
--

cxfRsConsumer[1] has the same problem, it's better to fix that part of code too.

[1]https://github.com/apache/camel/blob/master/components/camel-cxf/src/main/java/org/apache/camel/component/cxf/jaxrs/CxfRsConsumer.java

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-9502) karaf - Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato reassigned CAMEL-9502:
-

Assignee: Tadayoshi Sato

> karaf - Re-installing bundle using camel-cxf throws 
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws 
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN  | pache.cxf.osgi]) | MBeanContainer   
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 |   | bean: 
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException: 
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
>   at 
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
>   at 
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:784)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> 

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10914:


Github user tadayosi closed the pull request at:

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


> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10908) Introduce DataTypeAware interface and let MessageSupport implement it

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10908:


Github user asfgit closed the pull request at:

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


> Introduce DataTypeAware interface and let MessageSupport implement it
> -
>
> Key: CAMEL-10908
> URL: https://issues.apache.org/jira/browse/CAMEL-10908
> Project: Camel
>  Issue Type: Task
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
> Fix For: 2.19.0
>
>
> Instead of carrying around the INPUT_TYPE/OUTPUT_TYPE exchange properties, 
> let Message hold the DataType directly as those exchange properties get out 
> of sync when Pipeline copies the message between IN and OUT.
> {code:java}
> public interface DataTypeAware {
> void setDataType(DataType type);
> 
> DataType getDataType();
> 
> setBody(Object body, DataType type);
> 
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10912) camel-sjms - Session object created from connection that gets closed

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10912:

Summary: camel-sjms - Session object created from connection that gets 
closed  (was: Session object created from connection that gets closed)

> camel-sjms - Session object created from connection that gets closed
> 
>
> Key: CAMEL-10912
> URL: https://issues.apache.org/jira/browse/CAMEL-10912
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sjms
>Affects Versions: 2.18.2
>Reporter: Ryan Yeats
>
> This is not easy to reproduce I haven't been able to simplify it down from 
> our code to recreate it but I can reliably cause it to happen.  Basically if 
> you hit a camel-sjms route with a spike of load from nothing and have a bunch 
> of .toD("dynamic-${route}") it can create more connections than the pool 
> allows then when a connection is returned it is closed and one of the routes 
> will be using a session with a closed connection and will not work until it 
> is restarted.
> The code in question:
> https://github.com/apache/camel/blob/camel-2.18.x/components/camel-sjms/src/main/java/org/apache/camel/component/sjms/producer/InOnlyProducer.java#L51-L67



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10906) http components: not all the options supported by component/endpoints are shown in the documentation

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10906:
-

Luca are you working on this? If no I can help with this

> http components: not all the options supported by component/endpoints are 
> shown in the documentation
> 
>
> Key: CAMEL-10906
> URL: https://issues.apache.org/jira/browse/CAMEL-10906
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
> Fix For: 2.19.0
>
>
> The http components documentation does not expose all the options an 
> endpoint/component supports and sometimes it reports them wrongly.
> i.e. camel-http4 uses proxyAuthHost/proxyAuthPort [1] to configure the proxy 
> but in the documentationreports proxyHost/proxyPort as endpoint options which 
> is not true.
> [1] 
> https://github.com/apache/camel/blame/master/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpComponent.java#L141-L164



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10912) camel-sjms - Session object created from connection that gets closed

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10912:
-

Sounds like maybe the pool code needs some code that does a "valid" check to 
check if that connection is alive and ready to be used. Not sure if that is the 
case but I havent dived into the code. You are welcome to take a look.


> camel-sjms - Session object created from connection that gets closed
> 
>
> Key: CAMEL-10912
> URL: https://issues.apache.org/jira/browse/CAMEL-10912
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sjms
>Affects Versions: 2.18.2
>Reporter: Ryan Yeats
>
> This is not easy to reproduce I haven't been able to simplify it down from 
> our code to recreate it but I can reliably cause it to happen.  Basically if 
> you hit a camel-sjms route with a spike of load from nothing and have a bunch 
> of .toD("dynamic-${route}") it can create more connections than the pool 
> allows then when a connection is returned it is closed and one of the routes 
> will be using a session with a closed connection and will not work until it 
> is restarted.
> The code in question:
> https://github.com/apache/camel/blob/camel-2.18.x/components/camel-sjms/src/main/java/org/apache/camel/component/sjms/producer/InOnlyProducer.java#L51-L67



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10753) Box component uses out of date library

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10753:
-

Contributions is welcome to help migrate to a new box client api library

> Box component uses out of date library
> --
>
> Key: CAMEL-10753
> URL: https://issues.apache.org/jira/browse/CAMEL-10753
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-box
>Affects Versions: 2.18.1
>Reporter: Tim Dudgeon
> Fix For: 2.19.0
>
>
> As discussed here: 
> http://camel.465427.n5.nabble.com/Using-Box-component-td5792922.html
> the box component is not functioning correctly, and it appears that this is a 
> result of an obsolete version of the box Java library being used.
> The latest one is here: 
> https://github.com/box/box-java-sdk with maven coordinates of
> com.box:box-java-sdk:2.1.1
> but the one used in Camel is net.box:boxjavalibv2:3.2.1 and has
> not been updated since 2014.
> It appears that this old library does not work with the current Box REST API.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10892) online camel-blueprint.xsd is not the latest one

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10892:
-

Gregor I wonder if you can update those schema files when doing the next 
release?

> online camel-blueprint.xsd is not the latest one
> 
>
> Key: CAMEL-10892
> URL: https://issues.apache.org/jira/browse/CAMEL-10892
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Aurelien Pupier
>Assignee: Gregor Zurowski
>Priority: Minor
>
> here: http://camel.apache.org/schema/blueprint/camel-blueprint.xsd is not the 
> latest one that we can have here: 
> http://camel.apache.org/schema/blueprint/camel-blueprint-2.18.2.xsd
> from http://camel.apache.org/schema/blueprint/ , we can see the modification 
> date:
> camel-blueprint-2.18.2.xsd2017-01-30 20:18425K 
> camel-blueprint.xsd   2016-08-03 14:08344K 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10892) online camel-blueprint.xsd is not the latest one

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10892:
---

Assignee: Gregor Zurowski

> online camel-blueprint.xsd is not the latest one
> 
>
> Key: CAMEL-10892
> URL: https://issues.apache.org/jira/browse/CAMEL-10892
> Project: Camel
>  Issue Type: Task
>  Components: website
>Reporter: Aurelien Pupier
>Assignee: Gregor Zurowski
>Priority: Minor
>
> here: http://camel.apache.org/schema/blueprint/camel-blueprint.xsd is not the 
> latest one that we can have here: 
> http://camel.apache.org/schema/blueprint/camel-blueprint-2.18.2.xsd
> from http://camel.apache.org/schema/blueprint/ , we can see the modification 
> date:
> camel-blueprint-2.18.2.xsd2017-01-30 20:18425K 
> camel-blueprint.xsd   2016-08-03 14:08344K 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10831) camel examples - Add readme files for missing examples

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10831:
-

[~nferraro] I wonder when you get a chance to work on the stream components 
again if you would mind adding some readme to these examples

> camel examples - Add readme files for missing examples
> --
>
> Key: CAMEL-10831
> URL: https://issues.apache.org/jira/browse/CAMEL-10831
> Project: Camel
>  Issue Type: Improvement
>  Components: examples
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 2.19.0
>
>
> Some examples dont have readme files
> - java8
> - java8 rx
> - reactive streams



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10831) camel examples - Add readme files for missing examples

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10831:
---

Assignee: Nicola Ferraro

> camel examples - Add readme files for missing examples
> --
>
> Key: CAMEL-10831
> URL: https://issues.apache.org/jira/browse/CAMEL-10831
> Project: Camel
>  Issue Type: Improvement
>  Components: examples
>Reporter: Claus Ibsen
>Assignee: Nicola Ferraro
>Priority: Minor
> Fix For: 2.19.0
>
>
> Some examples dont have readme files
> - java8
> - java8 rx
> - reactive streams



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10829) [jruby] Issue with multithreading and finalize()

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10829:
-

We should deprecate those script langauges like php, python, ruby etc and only 
support javascript from the JDK itself with nashhorn

> [jruby] Issue with multithreading and finalize()
> 
>
> Key: CAMEL-10829
> URL: https://issues.apache.org/jira/browse/CAMEL-10829
> Project: Camel
>  Issue Type: Bug
>  Components: camel-script
>Affects Versions: 2.18.2
>Reporter: Paolo Antinori
>
> There is a rare to hit issue with {{camel-script}} component and {{jruby}}.
> {{camel-script}} passes through this method chain to create a {{jruby}} 
> {{ScriptEngine}}:
> https://github.com/apache/camel/blob/master/components/camel-script/src/main/java/org/apache/camel/builder/script/ScriptBuilder.java#L267-L269
> {code:java}
> public static boolean supportScriptLanguage(String language) {
> return createScriptEngine(language, true) != null;
> }
> {code}
> *The problem with that code is that it creates a Script Engine instance, but 
> it doesn't keep a reference to that  object.*
> JRuby gives a specialized behavior to {{finalize()}} method of its runtime:
> https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929
> The combination of the 2 conditions is able to cause situation where the 
> {{gc()}} thread, reaps JRuby instances, triggering their clean up methods:
> https://github.com/jruby/jruby/blob/jruby-1_7/core/src/main/java/org/jruby/embed/ScriptingContainer.java#L1907-L1929t
> before Camel has really finished using it.
> This behavior can be noticed in 
> https://github.com/apache/camel/blob/master/components/camel-script/src/test/java/org/apache/camel/builder/script/JRubySingletonTest.java
>  failing every now and then. Event more frequent when we tried to upgrade to 
> jruby 1.7.26: 
> https://issues.apache.org/jira/browse/CAMEL-10477
> {code}
> "main@1" prio=5 tid=0x1 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
> at 
> org.apache.camel.builder.script.ScriptBuilder.tryCreateScriptEngine(ScriptBuilder.java:359)
> at 
> org.apache.camel.builder.script.ScriptBuilder.createScriptEngine(ScriptBuilder.java:336)
> at 
> org.apache.camel.builder.script.ScriptBuilder.supportScriptLanguage(ScriptBuilder.java:268)
> at 
> org.apache.camel.builder.script.ScriptLanguageResolver.resolveLanguage(ScriptLanguageResolver.java:30)
> at 
> org.apache.camel.builder.script.RubyLanguage.createExpression(RubyLanguage.java:38)
> at 
> org.apache.camel.component.language.LanguageEndpoint.createProducer(LanguageEndpoint.java:96)
> at 
> org.apache.camel.impl.ProducerCache.doGetProducer(ProducerCache.java:439)
> - locked <0x1806> (a org.apache.camel.impl.ProducerCache)
> at 
> org.apache.camel.impl.ProducerCache.acquireProducer(ProducerCache.java:160)
> at 
> org.apache.camel.processor.SendProcessor.doStart(SendProcessor.java:243)
> {code}
> Now, I honestly don't know if this should be fixed on Camel side (and reason 
> if the scripting API needs to be changed for other runtimes too), or  this 
> should be handled on JRuby one.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10820) DefaultFluentProducerTemplate mixes up data when sending asynchronously

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10820:
-

Ah well spotted.

I wonder if you fancy taking a stab at trying to implement a fix for this? Not 
sure on top of my head how to do this, but maybe somehow with async send the 
state of the template must be computed and send asap. Or you need some kind of 
Stack to push/pop when doing multiple sends or something.



> DefaultFluentProducerTemplate mixes up data when sending asynchronously
> ---
>
> Key: CAMEL-10820
> URL: https://issues.apache.org/jira/browse/CAMEL-10820
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.18.2
> Environment: eclipse, win7, gradle
>Reporter: Jakub Cernohorsky
> Fix For: 2.18.3, 2.19.0
>
>
> DefaultFluentProducerTemplate
> code:
> producer = context.createFluentProducerTemplate();
> future1 = producer.withHeader("action", 
> "register").withBody(body1).asyncSend();
> future2 = producer.withHeader("action", 
> "register").withBody(body2).asyncSend();
> These two subsequent calls produces with the default creation two calls with 
> the same body - body2.
> The cause is that it uses default processor supplier () -> 
> this::populateExchange which is call lazily at the time of send and at that 
> time the body property of DefaultFluentProducerTemplate is body2.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10903) Getting Error due to higher version of JSCH

[Sourabh Jain (JIRA)]

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

Sourabh Jain commented on CAMEL-10903:
--

Hi Claus,

I tried dropping mail to jsch on all email id but it ail to delivered because 
of no memory on there server.
Do you know any way to reach out to them.

 

> Getting Error due to higher version of JSCH
> ---
>
> Key: CAMEL-10903
> URL: https://issues.apache.org/jira/browse/CAMEL-10903
> Project: Camel
>  Issue Type: Task
>  Components: camel-ftp
>Affects Versions: 2.16.2
>Reporter: Sourabh Jain
>Priority: Minor
>
> Hi, We are getting error when we are using higher version(0.1.53) of JSCH 
> jar. but it work fine with JSCH version (0.1.49) while using camel-ftp route 
> while making SFTP connection. Here we are using the proxy for getting 
> connected to SFTP. Please let me know if you need more detail. 
> Please find the below error :  
> This is the set of credentials was provided by HSBC but we were getting the 
> following error:
> org.apache.camel.component.file.GenericFileOperationFailedException: Cannot 
> connect to sftp://x...@ftp.:22
>at 
> org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:146)
>at 
> org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:203)
>at 
> org.apache.camel.component.file.remote.SftpConsumer.doStart(SftpConsumer.java:52)
>at 
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
>at 
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3269)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:3563)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartRouteConsumers(DefaultCamelContext.java:3499)
>at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3429)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3197)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3053)
>at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
>at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2848)
>at 
> 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.onApplicationEvent(SpringCamelContext.java:136)
>at 
> org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:340)
>at 
> org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
>at 
> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
>at 
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:380)
>at 
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)
>at 
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:851)
>at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:540)
>at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
>at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:93)
>at com.bfm.etf.dixie.BDServer.loadApplicationContext(BDServer.java:98)
>at com.bfm.etf.dixie.BDServer.main(BDServer.java:60)
> Caused by: com.jcraft.jsch.JSchException: Session.connect: 
> java.security.InvalidAlgorithmParameterException: Prime size must be multiple 
> of 64, and can only range from 512 to 2048 (inclusive)
>at com.jcraft.jsch.Session.connect(Session.java:558)
>at 
> org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:118)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10789) Indexing with simple expression broken in Apache Camel 2.18

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10789:
---

Assignee: Claus Ibsen

> Indexing with simple expression broken in Apache Camel 2.18
> ---
>
> Key: CAMEL-10789
> URL: https://issues.apache.org/jira/browse/CAMEL-10789
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.18.0, 2.18.1, 2.18.2
> Environment: Camel 2.18.0/2.18.1/2.18.2 with JDK 1.8.0_112
>Reporter: Surjit Sen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.3
>
>
> The following sample code works fine with version 2.17.4 (JDK 1.7), but fails 
> on Camel 2.18.0, 2.18.1 and 2.18.2 (JDK 1.8)
> {code}
> from("direct:process")
> .process(new Processor() {
> public void process(Exchange exchange) {
> List alist = new ArrayList();
> alist.add("1");
> alist.add("99");
> exchange.getIn().setHeader("ITEMS", alist);
> exchange.getIn().setHeader("TOTAL_LOOPS", alist.size());
> }
> })
> .loop(simple("${header.TOTAL_LOOPS}", Integer.class))
>   .setHeader("item", 
> simple("${header.ITEMS[${property.CamelLoopIndex}]}", String.class))
>   .log(LoggingLevel.INFO, LOG_CLASS_NAME, simple("item = 
> ${header.item} and TOTAL_MAPS = ${header.TOTAL_LOOPS}").getText())
> .end()
> .end();
> {code}
> With 2.18.x, the following exception gets thrown:
> {code}
> 2017-02-03 21:13:31 ERROR DefaultErrorHandler:204 - Failed delivery for 
> (MessageId: ID-CATL0W10D4DG4R1-55822-1486174410756-0-1 on ExchangeId: 
> ID-CATL0W10D4DG4R1-55822-1486174410756-0-2). Exhausted after delivery 
> attempt: 1 caught: 
> org.apache.camel.language.bean.RuntimeBeanExpressionException: Failed to 
> invoke method: [${property.CamelLoopIndex}] on java.util.ArrayList due to: 
> java.lang.IndexOutOfBoundsException: Key: ${property.CamelLoopIndex} not 
> found in bean: [1, 99] of type: java.util.ArrayList using OGNL path 
> [[${property.CamelLoopIndex}]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10789) Indexing with simple expression broken in Apache Camel 2.18

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10789.
-
Resolution: Fixed

> Indexing with simple expression broken in Apache Camel 2.18
> ---
>
> Key: CAMEL-10789
> URL: https://issues.apache.org/jira/browse/CAMEL-10789
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.18.0, 2.18.1, 2.18.2
> Environment: Camel 2.18.0/2.18.1/2.18.2 with JDK 1.8.0_112
>Reporter: Surjit Sen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.3
>
>
> The following sample code works fine with version 2.17.4 (JDK 1.7), but fails 
> on Camel 2.18.0, 2.18.1 and 2.18.2 (JDK 1.8)
> {code}
> from("direct:process")
> .process(new Processor() {
> public void process(Exchange exchange) {
> List alist = new ArrayList();
> alist.add("1");
> alist.add("99");
> exchange.getIn().setHeader("ITEMS", alist);
> exchange.getIn().setHeader("TOTAL_LOOPS", alist.size());
> }
> })
> .loop(simple("${header.TOTAL_LOOPS}", Integer.class))
>   .setHeader("item", 
> simple("${header.ITEMS[${property.CamelLoopIndex}]}", String.class))
>   .log(LoggingLevel.INFO, LOG_CLASS_NAME, simple("item = 
> ${header.item} and TOTAL_MAPS = ${header.TOTAL_LOOPS}").getText())
> .end()
> .end();
> {code}
> With 2.18.x, the following exception gets thrown:
> {code}
> 2017-02-03 21:13:31 ERROR DefaultErrorHandler:204 - Failed delivery for 
> (MessageId: ID-CATL0W10D4DG4R1-55822-1486174410756-0-1 on ExchangeId: 
> ID-CATL0W10D4DG4R1-55822-1486174410756-0-2). Exhausted after delivery 
> attempt: 1 caught: 
> org.apache.camel.language.bean.RuntimeBeanExpressionException: Failed to 
> invoke method: [${property.CamelLoopIndex}] on java.util.ArrayList due to: 
> java.lang.IndexOutOfBoundsException: Key: ${property.CamelLoopIndex} not 
> found in bean: [1, 99] of type: java.util.ArrayList using OGNL path 
> [[${property.CamelLoopIndex}]]
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10896) camel-infinispan - Stores result in header and not body

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10896:

Priority: Minor  (was: Major)

> camel-infinispan - Stores result in header and not body
> ---
>
> Key: CAMEL-10896
> URL: https://issues.apache.org/jira/browse/CAMEL-10896
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-infinispan
>Reporter: Claus Ibsen
>Priority: Minor
>
> This component sadly does not work like others like hazelcast etc where the 
> result is by default in message body, so it stores all magically in some 
> result header which you do not expect. 
> So if you want to store some message body in a map cache you have to use 
> headers and whatnot.
> We should add some way to configure this to work more like the others. Also 
> it should have better NPE check as you can get NPEs such as
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.camel.component.infinispan.InfinispanOperation$Operation$7.execute(InfinispanOperation.java:183)
>   at 
> org.apache.camel.component.infinispan.InfinispanOperation.process(InfinispanOperation.java:45)
>   at 
> org.apache.camel.component.infinispan.InfinispanProducer.process(InfinispanProducer.java:34)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10768) Dropbox component should support specifying route params using headers

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10768:
-

Contributions is welcome

> Dropbox component should support specifying route params using headers
> --
>
> Key: CAMEL-10768
> URL: https://issues.apache.org/jira/browse/CAMEL-10768
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Tim Dudgeon
> Fix For: Future
>
>
> Unlike similar components it seems that the Dropbox component does not allow 
> to specify key parameters (such as the file name) using headers.
> Doing so would make it much more useful.
> See discussion here:
> http://camel.465427.n5.nabble.com/Specifying-file-names-using-Dropbox-component-td5793105.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10768) Dropbox component should support specifying route params using headers

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10768:

Fix Version/s: Future

> Dropbox component should support specifying route params using headers
> --
>
> Key: CAMEL-10768
> URL: https://issues.apache.org/jira/browse/CAMEL-10768
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-dropbox
>Reporter: Tim Dudgeon
> Fix For: Future
>
>
> Unlike similar components it seems that the Dropbox component does not allow 
> to specify key parameters (such as the file name) using headers.
> Doing so would make it much more useful.
> See discussion here:
> http://camel.465427.n5.nabble.com/Specifying-file-names-using-Dropbox-component-td5793105.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10831) camel examples - Add readme files for missing examples

[Nicola Ferraro (JIRA)]

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

Nicola Ferraro commented on CAMEL-10831:


Yeah, I had a note written somewhere :) .. I'll do it today.

> camel examples - Add readme files for missing examples
> --
>
> Key: CAMEL-10831
> URL: https://issues.apache.org/jira/browse/CAMEL-10831
> Project: Camel
>  Issue Type: Improvement
>  Components: examples
>Reporter: Claus Ibsen
>Assignee: Nicola Ferraro
>Priority: Minor
> Fix For: 2.19.0
>
>
> Some examples dont have readme files
> - java8
> - java8 rx
> - reactive streams



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10721) Camel Connectors

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10721.
-
Resolution: Fixed

> Camel Connectors
> 
>
> Key: CAMEL-10721
> URL: https://issues.apache.org/jira/browse/CAMEL-10721
> Project: Camel
>  Issue Type: New Feature
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.19.0
>
>
> Introduce Camel Connectors.
> A Camel Connectors is a simplified and pre-configured Camel component which 
> has been setup for a specific use-case, such as "add new contact to 
> salesforce", or "add calender entry" or whatever.
> This would allow to build a marketplace/catalog of Camel connectors which 
> would be easier to use for business use-cases. 
> The connector is based on one of the existing Camel components (or 3rd party 
> component) by which you can specify in a camel-connector.json file which 
> options to pre-select and as well specify other default values etc. 
> Then a maven plugin will build this as a Camel component, so at runtime its 
> just a regular Camel component. 
> And because they are just regular Camel component then there is no problem 
> running them in Camel applications. 
> In addition all existing JMX, tooling et all just sees this as Camel 
> components and can use that.
> Also at design time, for example the IDEA plugin will see the connector as a 
> 3rd party Camel component and offer code assistance to it etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10668:

Fix Version/s: Future

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10668:
-

This is a bit tricker as its EIP configuration. But it would be good to do this 
for other things like error handler etc.

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10627) Live reload for Java DSL routes

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10627:

Estimated Complexity: Advanced  (was: Unknown)

> Live reload for Java DSL routes
> ---
>
> Key: CAMEL-10627
> URL: https://issues.apache.org/jira/browse/CAMEL-10627
> Project: Camel
>  Issue Type: New Feature
>  Components: tooling
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> Tweeted about live reload for XML
> https://twitter.com/davsclaus/status/811226802874175488
> And wonder if we can do it for Java DSL (limited possibilities).
> But we still need to build that tool that parses your Java code and build the 
> route model in memory (we do fetch endpoints and expressions today). And with 
> that in mind, we could build the model, and output as XML for live java 
> update.
> There are some corner cases and if you use Java lamdas etc its not possible.
> Then again people can use JRebel or other tooling for hot reload of Java 
> .class files.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10627) Live reload for Java DSL routes

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10627:

Priority: Minor  (was: Major)

> Live reload for Java DSL routes
> ---
>
> Key: CAMEL-10627
> URL: https://issues.apache.org/jira/browse/CAMEL-10627
> Project: Camel
>  Issue Type: New Feature
>  Components: tooling
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> Tweeted about live reload for XML
> https://twitter.com/davsclaus/status/811226802874175488
> And wonder if we can do it for Java DSL (limited possibilities).
> But we still need to build that tool that parses your Java code and build the 
> route model in memory (we do fetch endpoints and expressions today). And with 
> that in mind, we could build the model, and output as XML for live java 
> update.
> There are some corner cases and if you use Java lamdas etc its not possible.
> Then again people can use JRebel or other tooling for hot reload of Java 
> .class files.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10587) Extending SQS message invisibility timeout not working in some cases

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10587:
-

Can you turn on trace logging on: org.apache.camel.component.aws.sqs.SqsConsumer

As it should do a TRACE log when it extends the visibility, and then observe if 
it does that for all 10 messages.

I also change the code to start the scheduler before the consumer so the 
extender is always created in case of some startup race condition otherwise.

> Extending SQS message invisibility timeout not working in some cases
> 
>
> Key: CAMEL-10587
> URL: https://issues.apache.org/jira/browse/CAMEL-10587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-aws
>Affects Versions: 2.18.0
>Reporter: Sindre Mehus
>
> org.apache.camel.component.aws.sqs.SqsConsumer creates a TimeoutExtender task 
> for each message received in a batch, but these tasks should be started 
> *before* processing the messages.
> Error can be reproduced as follows:
> 1. Create an SQS-consuming route using maxMessagesPerPoll=10, 
> extendMessageVisibility=true, visibilityTimeout=30, waitTimeSeconds=20.
> 2. Add a process step in the route which just sleeps for a long time.
> 3. Put 20-30 messages on the SQS queue.
> 4. Start the route.
> 5. Let's say the SQS consumer reads off 10 messages.
> 6. Observe in the AWS SQS console that 10 messages are in-flight.
> 7. After 30 seconds you can observe that only 1 message is in-flight. This is 
> incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10587) Extending SQS message invisibility timeout not working in some cases

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10587:

Fix Version/s: 2.19.0
   2.18.3

> Extending SQS message invisibility timeout not working in some cases
> 
>
> Key: CAMEL-10587
> URL: https://issues.apache.org/jira/browse/CAMEL-10587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-aws
>Affects Versions: 2.18.0
>Reporter: Sindre Mehus
> Fix For: 2.18.3, 2.19.0
>
>
> org.apache.camel.component.aws.sqs.SqsConsumer creates a TimeoutExtender task 
> for each message received in a batch, but these tasks should be started 
> *before* processing the messages.
> Error can be reproduced as follows:
> 1. Create an SQS-consuming route using maxMessagesPerPoll=10, 
> extendMessageVisibility=true, visibilityTimeout=30, waitTimeSeconds=20.
> 2. Add a process step in the route which just sleeps for a long time.
> 3. Put 20-30 messages on the SQS queue.
> 4. Start the route.
> 5. Let's say the SQS consumer reads off 10 messages.
> 6. Observe in the AWS SQS console that 10 messages are in-flight.
> 7. After 30 seconds you can observe that only 1 message is in-flight. This is 
> incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10587) Extending SQS message invisibility timeout not working in some cases

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10587:
-

As the extender task is one per message, I think it would make more sense to 
make it one per batch, and then let it loop all the messages in the batch. 
Otherwise if you have 100 messages in a batch its 100 tasks on the thread pool 
to execute and there is only 1 thread.

In Camel JMX you should see the SqsTimeoutExtender thread pool and you can see 
how deep its task queue is at runtime and see if there is outstanding tasks 
that are not run.

> Extending SQS message invisibility timeout not working in some cases
> 
>
> Key: CAMEL-10587
> URL: https://issues.apache.org/jira/browse/CAMEL-10587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-aws
>Affects Versions: 2.18.0
>Reporter: Sindre Mehus
> Fix For: 2.18.3, 2.19.0
>
>
> org.apache.camel.component.aws.sqs.SqsConsumer creates a TimeoutExtender task 
> for each message received in a batch, but these tasks should be started 
> *before* processing the messages.
> Error can be reproduced as follows:
> 1. Create an SQS-consuming route using maxMessagesPerPoll=10, 
> extendMessageVisibility=true, visibilityTimeout=30, waitTimeSeconds=20.
> 2. Add a process step in the route which just sleeps for a long time.
> 3. Put 20-30 messages on the SQS queue.
> 4. Start the route.
> 5. Let's say the SQS consumer reads off 10 messages.
> 6. Observe in the AWS SQS console that 10 messages are in-flight.
> 7. After 30 seconds you can observe that only 1 message is in-flight. This is 
> incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10587) Extending SQS message invisibility timeout not working in some cases

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10587:
-

We can maybe use the batch request instead (up to 10 messages)
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibilityBatch.html



> Extending SQS message invisibility timeout not working in some cases
> 
>
> Key: CAMEL-10587
> URL: https://issues.apache.org/jira/browse/CAMEL-10587
> Project: Camel
>  Issue Type: Bug
>  Components: camel-aws
>Affects Versions: 2.18.0
>Reporter: Sindre Mehus
> Fix For: 2.18.3, 2.19.0
>
>
> org.apache.camel.component.aws.sqs.SqsConsumer creates a TimeoutExtender task 
> for each message received in a batch, but these tasks should be started 
> *before* processing the messages.
> Error can be reproduced as follows:
> 1. Create an SQS-consuming route using maxMessagesPerPoll=10, 
> extendMessageVisibility=true, visibilityTimeout=30, waitTimeSeconds=20.
> 2. Add a process step in the route which just sleeps for a long time.
> 3. Put 20-30 messages on the SQS queue.
> 4. Start the route.
> 5. Let's say the SQS consumer reads off 10 messages.
> 6. Observe in the AWS SQS console that 10 messages are in-flight.
> 7. After 30 seconds you can observe that only 1 message is in-flight. This is 
> incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli commented on CAMEL-10668:
-

Should we do the same for ServiceCall ? I can work on both later on if needed 

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10906) http components: not all the options supported by component/endpoints are shown in the documentation

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli commented on CAMEL-10906:
-

Not yet so you're welcome :)

> http components: not all the options supported by component/endpoints are 
> shown in the documentation
> 
>
> Key: CAMEL-10906
> URL: https://issues.apache.org/jira/browse/CAMEL-10906
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
> Fix For: 2.19.0
>
>
> The http components documentation does not expose all the options an 
> endpoint/component supports and sometimes it reports them wrongly.
> i.e. camel-http4 uses proxyAuthHost/proxyAuthPort [1] to configure the proxy 
> but in the documentationreports proxyHost/proxyPort as endpoint options which 
> is not true.
> [1] 
> https://github.com/apache/camel/blame/master/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpComponent.java#L141-L164



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10537:
-

This is currently not supported to remove rest's at runtime

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10537:

Issue Type: Improvement  (was: Bug)

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10537:
---

Assignee: Claus Ibsen

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10906) http components: not all the options supported by component/endpoints are shown in the documentation

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10906:
---

Assignee: Claus Ibsen

> http components: not all the options supported by component/endpoints are 
> shown in the documentation
> 
>
> Key: CAMEL-10906
> URL: https://issues.apache.org/jira/browse/CAMEL-10906
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
>Assignee: Claus Ibsen
> Fix For: 2.19.0
>
>
> The http components documentation does not expose all the options an 
> endpoint/component supports and sometimes it reports them wrongly.
> i.e. camel-http4 uses proxyAuthHost/proxyAuthPort [1] to configure the proxy 
> but in the documentationreports proxyHost/proxyPort as endpoint options which 
> is not true.
> [1] 
> https://github.com/apache/camel/blame/master/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpComponent.java#L141-L164



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10668:
-

Yeah that would be good too

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10537:

Fix Version/s: 2.19.0
   2.18.3

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10537:
-

Okay found a solution to make this supported - it was a problem with rest 
configuration not being registered/used correctly when adding the new routes 
causing it to not use the existing jetty configuration and lead to duplicate 
issue.

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen edited comment on CAMEL-10537 at 3/1/17 10:32 AM:
--

This is currently not intended to be supported to remove / add rest's at 
runtime, however we can make it do so


was (Author: davsclaus):
This is currently not supported to remove rest's at runtime

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10537:

Issue Type: Bug  (was: Improvement)

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli commented on CAMEL-10668:
-

question: should any additional custom conf inherit from the default ?

i.e. :
{code:xml}






   

{code}

So the conf on the route inherit from myconf which inherit from the deault one.


> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10750) Suppression of JSR356 should be restricted to Jetty

[James Netherton (JIRA)]

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

James Netherton commented on CAMEL-10750:
-

Yes, I did take a brief look at it. I removed the WEBSOCKET_SUPPRESS_JSR356 
flag and the tests all passed fine (which run with Jetty 9.3.x).

I'll do some additional testing and try to get a PR in this week.

> Suppression of JSR356 should be restricted to Jetty
> ---
>
> Key: CAMEL-10750
> URL: https://issues.apache.org/jira/browse/CAMEL-10750
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-atmosphere-websocket
>Reporter: James Netherton
>Assignee: James Netherton
> Fix For: 2.19.0
>
>
> We have some logic that sets up the atmosphere websocket config in the 
> WebsocketConsumer.
> https://github.com/apache/camel/blame/52a739feb9da8acd29067304c7c8356bbc5ef4dd/components/camel-atmosphere-websocket/src/main/java/org/apache/camel/component/atmosphere/websocket/WebsocketConsumer.java#L53-L54
> If suppression of JSR 356 is specific to running on Jetty, why do we enforce 
> it globally?
> I'm trying to integrate this component on WildFly so it seems reasonable to 
> me that I should be able to make use of JSR 356.
> Maybe we should only apply this restriction if Jetty is detected? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10913) CORS header Access-Control-Allow-Credentials not managed correctly

[Nicola Ferraro (JIRA)]

Nicola Ferraro created CAMEL-10913:
--

 Summary: CORS header Access-Control-Allow-Credentials not managed 
correctly
 Key: CAMEL-10913
 URL: https://issues.apache.org/jira/browse/CAMEL-10913
 Project: Camel
  Issue Type: Bug
  Components: camel-http-common
Reporter: Nicola Ferraro


When a browser uses the "withCredentials" flag (not visible in HTTP request 
headers), it accepts the response only if the 
"Access-Control-Allow-Credentials" header returned by the server is set to 
"true".

That header is not part of Camel standard cors headers, but it can be set in 
the route. The problem is that when "Access-Control-Allow-Credentials" is set 
to "true", the "Access-Control-Allow-Origin" header cannot be set to "*", which 
is our default (https://www.w3.org/TR/cors/ - section 6.1, point 3).

Setting a value for the "Access-Control-Allow-Origin" header equals to the 
"Origin" header of the request makes the trick, but this must be set per-route, 
and *CORS must be disabled*.

Eg. 
{code}
// do not enable cors
rest().get("/hello")
  .route()
  .to("direct:handle")
  .setHeader("Access-Control-Allow-Credentials", constant("true"))
  .setHeader("Access-Control-Allow-Origin", header("Origin"));
{code}

Otherwise the only option is setting a fixed allowed origin if you know it in 
advance.

I wonder if we should add e.g. a ".corsAllowCredentials(boolean)" configuration 
to handle this situation correctly, or another flag to reflect the origin 
instead of returning "*".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10668:
-

My initial thought would be yes. What do you think? Or how does it work today?

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli commented on CAMEL-10668:
-

I do not remember such a hierarchy, as far as I remember it stops on the first 
parent but make sense to have such inheritance possible

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Tadayoshi Sato (JIRA)]

Tadayoshi Sato created CAMEL-10914:
--

 Summary: CxfConsumer doesn't clean up the CXF endpoint MBean upon 
stop
 Key: CAMEL-10914
 URL: https://issues.apache.org/jira/browse/CAMEL-10914
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.18.2
Reporter: Tadayoshi Sato


{{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
{{server.destroy()}}:
{code:java}
protected void doStop() throws Exception {
server.stop();
super.doStop();
}
{code}
This leads to a growing number of dangling endpoint MBeans on CXF side which 
are never used.

To reproduce the issue, extract the attached reproducer 
{{camel-cxf-hawtio.zip}} and do the following steps:

# Run the following command:
{code}
$ mvn hawtio:camel
{code}
# Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
route {{cxf-greeting}} several times.
# Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10915) Add type conversion support for java.net.URI

[Zoran Regvart (JIRA)]

Zoran Regvart created CAMEL-10915:
-

 Summary: Add type conversion support for java.net.URI
 Key: CAMEL-10915
 URL: https://issues.apache.org/jira/browse/CAMEL-10915
 Project: Camel
  Issue Type: New Feature
Affects Versions: 2.19.0
Reporter: Zoran Regvart
Assignee: Zoran Regvart
Priority: Trivial


Adding type conversion support for {{java.net.URI}} should encourage the use 
{{java.net.URI}} in place of {{java.net.URL}} -- that can block.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato updated CAMEL-10914:
---
External issue URL: https://issues.jboss.org/browse/ENTESB-6605

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Tadayoshi Sato (JIRA)]

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

Tadayoshi Sato updated CAMEL-10914:
---
Attachment: camel-cxf-hawtio.zip

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10915) Add type conversion support for java.net.URI

[Zoran Regvart (JIRA)]

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

Zoran Regvart resolved CAMEL-10915.
---
   Resolution: Fixed
Fix Version/s: 2.19.0

> Add type conversion support for java.net.URI
> 
>
> Key: CAMEL-10915
> URL: https://issues.apache.org/jira/browse/CAMEL-10915
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Trivial
> Fix For: 2.19.0
>
>
> Adding type conversion support for {{java.net.URI}} should encourage the use 
> {{java.net.URI}} in place of {{java.net.URL}} -- that can block.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10914:


GitHub user tadayosi opened a pull request:

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

CAMEL-10914: CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

https://issues.apache.org/jira/browse/CAMEL-10914

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

$ git pull https://github.com/tadayosi/camel CAMEL-10914

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

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


commit 6d31d169dc17138ed02ad1164a4b2209729677fc
Author: Tadayoshi Sato 
Date:   2017-03-01T11:20:21Z

CAMEL-10914: CxfConsumer doesn't clean up the CXF endpoint MBean upon stop




> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10916) camel http4 component does not send a body when the http method DELETE is used

[Saravanakumar Selvaraj (JIRA)]

Saravanakumar Selvaraj created CAMEL-10916:
--

 Summary: camel http4 component does not send a body when the http 
method DELETE is used
 Key: CAMEL-10916
 URL: https://issues.apache.org/jira/browse/CAMEL-10916
 Project: Camel
  Issue Type: Bug
  Components: camel-http4
Affects Versions: 2.18.2
Reporter: Saravanakumar Selvaraj


The camel-http4 component doesn't forward the body when used in conjunction 
with a DELETE http method. This makes the use of http4 in a proxy configuration 
for a REST service more or less impossible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10916) camel http4 component does not send a body when the http method DELETE is used

[Saravanakumar Selvaraj (JIRA)]

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

Saravanakumar Selvaraj updated CAMEL-10916:
---
Description: The camel-http4 component doesn't forward the body when used 
in conjunction with a DELETE http method. . This makes the use of camel-http4 
to act as a proxy  for a REST service more or less impossible.  (was: The 
camel-http4 component doesn't forward the body when used in conjunction with a 
DELETE http method. This makes the use of http4 in a proxy configuration for a 
REST service more or less impossible.)

> camel http4 component does not send a body when the http method DELETE is used
> --
>
> Key: CAMEL-10916
> URL: https://issues.apache.org/jira/browse/CAMEL-10916
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http4
>Affects Versions: 2.18.2
>Reporter: Saravanakumar Selvaraj
>
> The camel-http4 component doesn't forward the body when used in conjunction 
> with a DELETE http method. . This makes the use of camel-http4 to act as a 
> proxy  for a REST service more or less impossible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10916) camel http4 component does not send a body when the http method DELETE is used

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10916:
-

HTTP delete ignores the body
http://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request

> camel http4 component does not send a body when the http method DELETE is used
> --
>
> Key: CAMEL-10916
> URL: https://issues.apache.org/jira/browse/CAMEL-10916
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http4
>Affects Versions: 2.18.2
>Reporter: Saravanakumar Selvaraj
>
> The camel-http4 component doesn't forward the body when used in conjunction 
> with a DELETE http method. . This makes the use of camel-http4 to act as a 
> proxy  for a REST service more or less impossible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10916) camel http4 component does not send a body when the http method DELETE is used

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10916.
-
Resolution: Won't Fix

> camel http4 component does not send a body when the http method DELETE is used
> --
>
> Key: CAMEL-10916
> URL: https://issues.apache.org/jira/browse/CAMEL-10916
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http4
>Affects Versions: 2.18.2
>Reporter: Saravanakumar Selvaraj
>
> The camel-http4 component doesn't forward the body when used in conjunction 
> with a DELETE http method. . This makes the use of camel-http4 to act as a 
> proxy  for a REST service more or less impossible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10916) camel http4 component does not send a body when the http method DELETE is used

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10916:
-

Its a HTTP client 4.x issue: 
https://issues.apache.org/jira/browse/HTTPCLIENT-1828

> camel http4 component does not send a body when the http method DELETE is used
> --
>
> Key: CAMEL-10916
> URL: https://issues.apache.org/jira/browse/CAMEL-10916
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http4
>Affects Versions: 2.18.2
>Reporter: Saravanakumar Selvaraj
>
> The camel-http4 component doesn't forward the body when used in conjunction 
> with a DELETE http method. . This makes the use of camel-http4 to act as a 
> proxy  for a REST service more or less impossible.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10914:
---

Assignee: Tadayoshi Sato

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10914:
-

Thanks Tada, I granted your user karma to self assign tickets in JIRA

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10914:

Fix Version/s: 2.19.0
   2.18.3

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10915) Add type conversion support for java.net.URI

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10915:
-

I had a comment on the commit on the @dev forum

> Add type conversion support for java.net.URI
> 
>
> Key: CAMEL-10915
> URL: https://issues.apache.org/jira/browse/CAMEL-10915
> Project: Camel
>  Issue Type: New Feature
>Affects Versions: 2.19.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Trivial
> Fix For: 2.19.0
>
>
> Adding type conversion support for {{java.net.URI}} should encourage the use 
> {{java.net.URI}} in place of {{java.net.URL}} -- that can block.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-9502) karaf - Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9502:


Okay there is a fix in that linked ticket

> karaf - Re-installing bundle using camel-cxf throws 
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws 
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN  | pache.cxf.osgi]) | MBeanContainer   
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 |   | bean: 
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException: 
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
>   at 
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
>   at 
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:784)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)[220:org.eclipse.jetty.servlet:9.2.10.v20150310]
>   at 
> 

[jira] [Resolved] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10537.
-
Resolution: Fixed

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10537) Unable to remove/add restful path to an existing endpoint

[Sergey Zolotaryov (JIRA)]

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

Sergey Zolotaryov commented on CAMEL-10537:
---

This  is great news, thank you, Claus

> Unable to remove/add restful path to an existing endpoint
> -
>
> Key: CAMEL-10537
> URL: https://issues.apache.org/jira/browse/CAMEL-10537
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Affects Versions: 2.18.0
> Environment: any
>Reporter: Sergey Zolotaryov
>Assignee: Claus Ibsen
> Fix For: 2.18.3, 2.19.0
>
> Attachments: RoutesTest.java
>
>
> I am trying to re-add a rest definition to an existing jetty 
> restConfiguration with the following exception:
> org.apache.camel.FailedToStartRouteException: Failed to start route issues 
> because of Multiple consumers for the same endpoint is not allowed: 
> jetty:http://localhost:8080/issues/%7Bisin%7D/%7Bsedol%7D?httpMethodRestrict=GET
> This is obviously a bug since the first time I can add multiple rest routes 
> to the same endpoint (jetty or any other). Later while trying to remove/add a 
> route I get this error. I attach a unit test to illustrate the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Andrea Cosentino (JIRA)]

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

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

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop

[Andrea Cosentino (JIRA)]

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

Andrea Cosentino updated CAMEL-10914:
-
Fix Version/s: 2.17.6

> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not 
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which 
> are never used.
> To reproduce the issue, extract the attached reproducer 
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the 
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10668) camel-hystrix - Allow to configure global hystrix configuration from spring boot auto configuration

[Luca Burgazzoli (JIRA)]

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

Luca Burgazzoli reassigned CAMEL-10668:
---

Assignee: Luca Burgazzoli

> camel-hystrix - Allow to configure global hystrix configuration from spring 
> boot auto configuration
> ---
>
> Key: CAMEL-10668
> URL: https://issues.apache.org/jira/browse/CAMEL-10668
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-hystrix, camel-spring-boot-starters
>Reporter: Claus Ibsen
>Assignee: Luca Burgazzoli
> Fix For: Future
>
>
> It would be nice if we could allow to configure camel-hystrix using spring 
> boot auto configuration, eg from the application.properties / yml file.
> Then you can easily set a global configured timeout, and those other hystrix 
> configurations.
> And with this we get tooling support which can show documentation at your 
> finger tips.
> This should be global configuration, which you can override in your camel 
> routes if you setup a local hystrix configuration there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (CAMEL-10907) http components: have a common way to express concepts like proxy

[Claus Ibsen (JIRA)]

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

Claus Ibsen reassigned CAMEL-10907:
---

Assignee: Claus Ibsen

> http components: have a common way to express concepts like proxy
> -
>
> Key: CAMEL-10907
> URL: https://issues.apache.org/jira/browse/CAMEL-10907
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
>Assignee: Claus Ibsen
>Priority: Minor
>
> As today camel-http-commons defines proxyHost/proxyPort as options to 
> configure the proxy but camel-http/camel-http4 have their own options so 
> there should be a common set of options all the components rely on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10894) XML Validator: Improve DTD handling

[Franz Forsthofer (JIRA)]

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

Franz Forsthofer commented on CAMEL-10894:
--

I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan 
Sioana are there. Thank you Tomohisa ans Stephan.

> XML Validator: Improve DTD handling
> ---
>
> Key: CAMEL-10894
> URL: https://issues.apache.org/jira/browse/CAMEL-10894
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, 
> 2.18.1, 2.18.2
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> The DTD handling in the XML Validator is not correct for StreamSources



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (CAMEL-10894) XML Validator: Improve DTD handling

[Franz Forsthofer (JIRA)]

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

Franz Forsthofer edited comment on CAMEL-10894 at 3/1/17 1:48 PM:
--

I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan 
Sioana are there. Thank you Tomohisa and Stephan.


was (Author: forsthofer):
I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan 
Sioana are there. Thank you Tomohisa ans Stephan.

> XML Validator: Improve DTD handling
> ---
>
> Key: CAMEL-10894
> URL: https://issues.apache.org/jira/browse/CAMEL-10894
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, 
> 2.18.1, 2.18.2
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> The DTD handling in the XML Validator is not correct for StreamSources



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CAMEL-10907) http components: have a common way to express concepts like proxy

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-10907:

Fix Version/s: 2.19.0

> http components: have a common way to express concepts like proxy
> -
>
> Key: CAMEL-10907
> URL: https://issues.apache.org/jira/browse/CAMEL-10907
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.19.0
>
>
> As today camel-http-commons defines proxyHost/proxyPort as options to 
> configure the proxy but camel-http/camel-http4 have their own options so 
> there should be a common set of options all the components rely on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10750) Suppression of JSR356 should be restricted to Jetty

[James Netherton (JIRA)]

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

James Netherton commented on CAMEL-10750:
-

Turns out removing this setting seems to cause some issues. I deployed a basic 
app to Jetty and TomEE and hit issues unless the SUPPRESS_JSR356 flag was set. 

Having thought about things some more, I don't think removing the flag will 
help me to integrate with WildFly anyway. 

So maybe we close this for now and take another look at how the atmosphere 
framework is bootstrapped and configured in future task.

> Suppression of JSR356 should be restricted to Jetty
> ---
>
> Key: CAMEL-10750
> URL: https://issues.apache.org/jira/browse/CAMEL-10750
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-atmosphere-websocket
>Reporter: James Netherton
>Assignee: James Netherton
> Fix For: 2.19.0
>
>
> We have some logic that sets up the atmosphere websocket config in the 
> WebsocketConsumer.
> https://github.com/apache/camel/blame/52a739feb9da8acd29067304c7c8356bbc5ef4dd/components/camel-atmosphere-websocket/src/main/java/org/apache/camel/component/atmosphere/websocket/WebsocketConsumer.java#L53-L54
> If suppression of JSR 356 is specific to running on Jetty, why do we enforce 
> it globally?
> I'm trying to integrate this component on WildFly so it seems reasonable to 
> me that I should be able to make use of JSR 356.
> Maybe we should only apply this restriction if Jetty is detected? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10750) Suppression of JSR356 should be restricted to Jetty

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10750:
-

Yeah that is fine, you are welcome to close this

> Suppression of JSR356 should be restricted to Jetty
> ---
>
> Key: CAMEL-10750
> URL: https://issues.apache.org/jira/browse/CAMEL-10750
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-atmosphere-websocket
>Reporter: James Netherton
>Assignee: James Netherton
> Fix For: 2.19.0
>
>
> We have some logic that sets up the atmosphere websocket config in the 
> WebsocketConsumer.
> https://github.com/apache/camel/blame/52a739feb9da8acd29067304c7c8356bbc5ef4dd/components/camel-atmosphere-websocket/src/main/java/org/apache/camel/component/atmosphere/websocket/WebsocketConsumer.java#L53-L54
> If suppression of JSR 356 is specific to running on Jetty, why do we enforce 
> it globally?
> I'm trying to integrate this component on WildFly so it seems reasonable to 
> me that I should be able to make use of JSR 356.
> Maybe we should only apply this restriction if Jetty is detected? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (CAMEL-10750) Suppression of JSR356 should be restricted to Jetty

[James Netherton (JIRA)]

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

James Netherton closed CAMEL-10750.
---
   Resolution: Won't Fix
Fix Version/s: (was: 2.19.0)

> Suppression of JSR356 should be restricted to Jetty
> ---
>
> Key: CAMEL-10750
> URL: https://issues.apache.org/jira/browse/CAMEL-10750
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-atmosphere-websocket
>Reporter: James Netherton
>Assignee: James Netherton
>
> We have some logic that sets up the atmosphere websocket config in the 
> WebsocketConsumer.
> https://github.com/apache/camel/blame/52a739feb9da8acd29067304c7c8356bbc5ef4dd/components/camel-atmosphere-websocket/src/main/java/org/apache/camel/component/atmosphere/websocket/WebsocketConsumer.java#L53-L54
> If suppression of JSR 356 is specific to running on Jetty, why do we enforce 
> it globally?
> I'm trying to integrate this component on WildFly so it seems reasonable to 
> me that I should be able to make use of JSR 356.
> Maybe we should only apply this restriction if Jetty is detected? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-10908) Introduce DataTypeAware interface and let MessageSupport implement it

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-10908:


GitHub user igarashitm opened a pull request:

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

CAMEL-10908 Fixed adoc

a follow up for the https://github.com/apache/camel/pull/1497 fixing 
transformer.adoc.

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

$ git pull https://github.com/igarashitm/camel CAMEL-10908-doc

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

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


commit 5c7b90bb425f6803f15a8a33d6c6b7323d9f9034
Author: Tomohisa Igarashi 
Date:   2017-03-02T02:42:06Z

CAMEL-10908 Fixed adoc




> Introduce DataTypeAware interface and let MessageSupport implement it
> -
>
> Key: CAMEL-10908
> URL: https://issues.apache.org/jira/browse/CAMEL-10908
> Project: Camel
>  Issue Type: Task
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Tomohisa Igarashi
>Assignee: Tomohisa Igarashi
> Fix For: 2.19.0
>
>
> Instead of carrying around the INPUT_TYPE/OUTPUT_TYPE exchange properties, 
> let Message hold the DataType directly as those exchange properties get out 
> of sync when Pipeline copies the message between IN and OUT.
> {code:java}
> public interface DataTypeAware {
> void setDataType(DataType type);
> 
> DataType getDataType();
> 
> setBody(Object body, DataType type);
> 
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10906) http components: not all the options supported by component/endpoints are shown in the documentation

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10906.
-
Resolution: Fixed

> http components: not all the options supported by component/endpoints are 
> shown in the documentation
> 
>
> Key: CAMEL-10906
> URL: https://issues.apache.org/jira/browse/CAMEL-10906
> Project: Camel
>  Issue Type: Bug
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
>Assignee: Claus Ibsen
> Fix For: 2.19.0
>
>
> The http components documentation does not expose all the options an 
> endpoint/component supports and sometimes it reports them wrongly.
> i.e. camel-http4 uses proxyAuthHost/proxyAuthPort [1] to configure the proxy 
> but in the documentationreports proxyHost/proxyPort as endpoint options which 
> is not true.
> [1] 
> https://github.com/apache/camel/blame/master/components/camel-http4/src/main/java/org/apache/camel/component/http4/HttpComponent.java#L141-L164



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10907) http components: have a common way to express concepts like proxy

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-10907.
-
Resolution: Fixed

> http components: have a common way to express concepts like proxy
> -
>
> Key: CAMEL-10907
> URL: https://issues.apache.org/jira/browse/CAMEL-10907
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-http, camel-http-common, camel-http4
>Reporter: Luca Burgazzoli
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.19.0
>
>
> As today camel-http-commons defines proxyHost/proxyPort as options to 
> configure the proxy but camel-http/camel-http4 have their own options so 
> there should be a common set of options all the components rely on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10831) camel examples - Add readme files for missing examples

[Nicola Ferraro (JIRA)]

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

Nicola Ferraro resolved CAMEL-10831.

Resolution: Fixed

> camel examples - Add readme files for missing examples
> --
>
> Key: CAMEL-10831
> URL: https://issues.apache.org/jira/browse/CAMEL-10831
> Project: Camel
>  Issue Type: Improvement
>  Components: examples
>Reporter: Claus Ibsen
>Assignee: Nicola Ferraro
>Priority: Minor
> Fix For: 2.19.0
>
>
> Some examples dont have readme files
> - java8
> - java8 rx
> - reactive streams



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-9502) karaf - Re-installing bundle using camel-cxf throws javax.management.InstanceAlreadyExistsException

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-9502.

   Resolution: Fixed
Fix Version/s: 2.19.0
   2.18.3
   2.17.6

Fixed by that other ticket

> karaf - Re-installing bundle using camel-cxf throws 
> javax.management.InstanceAlreadyExistsException
> ---
>
> Key: CAMEL-9502
> URL: https://issues.apache.org/jira/browse/CAMEL-9502
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf, karaf
>Affects Versions: 2.16.1
> Environment: Karaf 4.0.3
>Reporter: Ralf Steppacher
>Priority: Minor
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> Re-installing a bundle (in my case via a feature) that uses camel-cxf throws 
> 3 instances of {{javax.management.InstanceAlreadyExistsException}}:
> {noformat}
> 2016-01-12 09:57:15,974 | WARN  | pache.cxf.osgi]) | MBeanContainer   
> | 222 - org.eclipse.jetty.util - 9.2.10.v20150310 |   | bean: 
> org.eclipse.jetty.server.session.HashSessionIdManager@398c8e55
> javax.management.InstanceAlreadyExistsException: 
> org.eclipse.jetty.server.session:type=hashsessionidmanager,id=0
>   at 
> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)[:1.8.0_40]
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)[:1.8.0_40]
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)[:1.8.0_40]
>   at 
> org.eclipse.jetty.jmx.MBeanContainer.beanAdded(MBeanContainer.java:209)[214:org.eclipse.jetty.jmx:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:264)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.addBean(ContainerLifeCycle.java:228)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.updateBean(ContainerLifeCycle.java:777)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.Server.setSessionIdManager(Server.java:578)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.AbstractSessionManager.doStart(AbstractSessionManager.java:247)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.HashSessionManager.doStart(HashSessionManager.java:153)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doStart(SessionHandler.java:116)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)[222:org.eclipse.jetty.util:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:120)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:784)[219:org.eclipse.jetty.server:9.2.10.v20150310]
>   at 
> 

[jira] [Commented] (CAMEL-10903) Getting Error due to higher version of JSCH

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-10903:
-

No sorry that project is not so open as others, would like to see it on github 
etc.

> Getting Error due to higher version of JSCH
> ---
>
> Key: CAMEL-10903
> URL: https://issues.apache.org/jira/browse/CAMEL-10903
> Project: Camel
>  Issue Type: Task
>  Components: camel-ftp
>Affects Versions: 2.16.2
>Reporter: Sourabh Jain
>Priority: Minor
>
> Hi, We are getting error when we are using higher version(0.1.53) of JSCH 
> jar. but it work fine with JSCH version (0.1.49) while using camel-ftp route 
> while making SFTP connection. Here we are using the proxy for getting 
> connected to SFTP. Please let me know if you need more detail. 
> Please find the below error :  
> This is the set of credentials was provided by HSBC but we were getting the 
> following error:
> org.apache.camel.component.file.GenericFileOperationFailedException: Cannot 
> connect to sftp://x...@ftp.:22
>at 
> org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:146)
>at 
> org.apache.camel.component.file.remote.RemoteFileConsumer.connectIfNecessary(RemoteFileConsumer.java:203)
>at 
> org.apache.camel.component.file.remote.SftpConsumer.doStart(SftpConsumer.java:52)
>at 
> org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
>at 
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:3269)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:3563)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartRouteConsumers(DefaultCamelContext.java:3499)
>at 
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:3429)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:3197)
>at 
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:3053)
>at 
> org.apache.camel.impl.DefaultCamelContext.access$000(DefaultCamelContext.java:175)
>at 
> org.apache.camel.impl.DefaultCamelContext$2.call(DefaultCamelContext.java:2848)
>at 
> 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.onApplicationEvent(SpringCamelContext.java:136)
>at 
> org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:340)
>at 
> org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
>at 
> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
>at 
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:380)
>at 
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)
>at 
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:851)
>at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:540)
>at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
>at 
> org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:93)
>at com.bfm.etf.dixie.BDServer.loadApplicationContext(BDServer.java:98)
>at com.bfm.etf.dixie.BDServer.main(BDServer.java:60)
> Caused by: com.jcraft.jsch.JSchException: Session.connect: 
> java.security.InvalidAlgorithmParameterException: Prime size must be multiple 
> of 64, and can only range from 512 to 2048 (inclusive)
>at com.jcraft.jsch.Session.connect(Session.java:558)
>at 
> org.apache.camel.component.file.remote.SftpOperations.connect(SftpOperations.java:118)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CAMEL-10917) Implementations of RestProducerFactory should handle empty or null basePath and uriTemplate

[Zoran Regvart (JIRA)]

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

Zoran Regvart resolved CAMEL-10917.
---
   Resolution: Fixed
Fix Version/s: 2.19.0

> Implementations of RestProducerFactory should handle empty or null basePath 
> and uriTemplate
> ---
>
> Key: CAMEL-10917
> URL: https://issues.apache.org/jira/browse/CAMEL-10917
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, camel-http, camel-http4, camel-jetty, 
> camel-netty4-http, camel-restlet, camel-undertow
>Affects Versions: 2.19.0
>Reporter: Zoran Regvart
>Assignee: Zoran Regvart
>Priority: Minor
> Fix For: 2.19.0
>
>
> All RestProducerFactory implementations use code similar to:
> {code:java}
> String url;
> if (uriTemplate != null) {
> // http is already prefixed in base path
> url = String.format("%s/%s/%s", host, basePath, uriTemplate);
> } else {
> // http is already prefixed in base path
> url = String.format("%s/%s", host, basePath);
> }
> {code}
> This fails to account for {{basePath}} being null or empty, and 
> {{uriTemplate}} being empty, which results in the resulting {{url}} to either 
> have double slashes (e.g. {{http://host//uriTemplate}}) or {{"null"}} 
> {{String}} in {{url}} (e.g. {{http://host/null/uriTemplate}}).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CAMEL-10917) Implementations of RestProducerFactory should handle empty or null basePath and uriTemplate

[Zoran Regvart (JIRA)]

Zoran Regvart created CAMEL-10917:
-

 Summary: Implementations of RestProducerFactory should handle 
empty or null basePath and uriTemplate
 Key: CAMEL-10917
 URL: https://issues.apache.org/jira/browse/CAMEL-10917
 Project: Camel
  Issue Type: Improvement
  Components: camel-core, camel-http, camel-http4, camel-jetty, 
camel-netty4-http, camel-restlet, camel-undertow
Affects Versions: 2.19.0
Reporter: Zoran Regvart
Assignee: Zoran Regvart
Priority: Minor


All RestProducerFactory implementations use code similar to:

{code:java}
String url;
if (uriTemplate != null) {
// http is already prefixed in base path
url = String.format("%s/%s/%s", host, basePath, uriTemplate);
} else {
// http is already prefixed in base path
url = String.format("%s/%s", host, basePath);
}
{code}

This fails to account for {{basePath}} being null or empty, and {{uriTemplate}} 
being empty, which results in the resulting {{url}} to either have double 
slashes (e.g. {{http://host//uriTemplate}}) or {{"null"}} {{String}} in {{url}} 
(e.g. {{http://host/null/uriTemplate}}).





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CAMEL-8351) Spring-ws consumer ignores breadcrumbId http header

[ASF GitHub Bot (JIRA)]

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

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

GitHub user onders86 opened a pull request:

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

CAMEL-8351 - simple implementation for breadcrumbId to be set as camel 
exhange's header

simple implementation, if mimeheaders may have multiple values as string 
array for breadcrumbs header, breadcrumb generation strategy may need to be 
implemented and this may require a config uri param on the endpoint to inject 
such strategy

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

$ git pull https://github.com/onders86/camel CAMEL-8351

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

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


commit 0967cd8b298429be85de6d01c79ccd57af293864
Author: onders86 
Date:   2017-03-01T19:17:28Z

CAMEL-8351 - simple implementation for breadcrumbId to be set as camel 
exhange's header

commit 8af371fefc910c63b3850f798028041e4fbe5089
Author: onders86 
Date:   2017-03-01T19:22:23Z

CAMEL-8351 - simple implementation for breadcrumbId to be set as camel 
exhange's header




> Spring-ws consumer ignores breadcrumbId http header
> ---
>
> Key: CAMEL-8351
> URL: https://issues.apache.org/jira/browse/CAMEL-8351
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-ws
>Affects Versions: 2.14.1
>Reporter: Ralf Steppacher
>Assignee: onder sezgin
>
> The spring-ws consumer does not pick up a {{breadcrumbId}} HTTP header. I 
> tried to find a hook where I could jump in and make the breadcrumbId from the 
> HTTP headers available, but could not find any.
> The spring-ws endpoint ({{SpringWebserviceConsumer}}) does not care about 
> HTTP headers, only about SOAP headers and properties of the 
> {{org.springframework.ws.context.MessageContext}}. SOAP headers get converted 
> into exchange headers while message context properties get converted into 
> exchange properties. Properties could be added by using a 
> {{org.springframework.ws.server.EndpointInterceptor}}.
> A breadcrumbId property is not picked up by Camel though. The 
> {{org.apache.camel.impl.DefaultUnitOfWork}} creates a new breadcrumbId 
> because it only checks the headers of the in-message, not the exchange 
> properties for an already existing breadcrumb ID.
> A SOAPHeader "breadcrumbId" is copied over to the in-message headers and 
> picked up by the DefaultUnitOfWork, but it is not automagically converted 
> from {{org.springframework.ws.soap.saaj.SaajSoapHeaderElement}} to its text 
> content.
> Ideally the web service consumer would pick up the breadcrumId (and others) 
> from the HTTP headers and restore them as in-message headers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)