[jira] [Closed] (CAMEL-11784) Could not disable the tlsv1 and tlsv1.1

[JIRA]

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

Önder Sezgin closed CAMEL-11784.

Resolution: Invalid

> Could not disable the tlsv1 and tlsv1.1
> ---
>
> Key: CAMEL-11784
> URL: https://issues.apache.org/jira/browse/CAMEL-11784
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Reporter: East
>
> Hi,
> I tried to use below code to disable the weak TLS version, such as TLSv1.1 
> TLSv1 and SSLv3, only left TLSv1.2, but it does not work
> {code:java}
> JettyHttpComponent jettyComponent =
> getContext().getComponent("jetty", JettyHttpComponent.class);
> SslSelectChannelConnector sslConnector = new 
> SslSelectChannelConnector();
> SslContextFactory sslFactory = sslConnector.getSslContextFactory();
>  ..
> SSLContextParameters sslContextParameters = new 
> SSLContextParameters();
> SecureSocketProtocolsParameters secureSocketProtocols = new 
> SecureSocketProtocolsParameters();
> secureSocketProtocols.getSecureSocketProtocol().add("TLSv1.2");
> sslContextParameters.setSecureSocketProtocols(secureSocketProtocols);
> jettyComponent.setSslContextParameters(sslContextParameters);
> jettyComponent.setSslSocketConnectors(connectors);
> from("jetty:https://0.0.0.0:343/eastweb/;)
> {code}
> Could you help to have a support? thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11784) Could not disable the tlsv1 and tlsv1.1

[JIRA]

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

Önder Sezgin commented on CAMEL-11784:
--

Please first ask for help in user forum/SO

> Could not disable the tlsv1 and tlsv1.1
> ---
>
> Key: CAMEL-11784
> URL: https://issues.apache.org/jira/browse/CAMEL-11784
> Project: Camel
>  Issue Type: Bug
>  Components: camel-jetty
>Reporter: East
>
> Hi,
> I tried to use below code to disable the weak TLS version, such as TLSv1.1 
> TLSv1 and SSLv3, only left TLSv1.2, but it does not work
> {code:java}
> JettyHttpComponent jettyComponent =
> getContext().getComponent("jetty", JettyHttpComponent.class);
> SslSelectChannelConnector sslConnector = new 
> SslSelectChannelConnector();
> SslContextFactory sslFactory = sslConnector.getSslContextFactory();
>  ..
> SSLContextParameters sslContextParameters = new 
> SSLContextParameters();
> SecureSocketProtocolsParameters secureSocketProtocols = new 
> SecureSocketProtocolsParameters();
> secureSocketProtocols.getSecureSocketProtocol().add("TLSv1.2");
> sslContextParameters.setSecureSocketProtocols(secureSocketProtocols);
> jettyComponent.setSslContextParameters(sslContextParameters);
> jettyComponent.setSslSocketConnectors(connectors);
> from("jetty:https://0.0.0.0:343/eastweb/;)
> {code}
> Could you help to have a support? thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11784) Could not disable the tlsv1 and tlsv1.1

[East (JIRA)]

East created CAMEL-11784:


 Summary: Could not disable the tlsv1 and tlsv1.1
 Key: CAMEL-11784
 URL: https://issues.apache.org/jira/browse/CAMEL-11784
 Project: Camel
  Issue Type: Bug
  Components: camel-jetty
Reporter: East


Hi,

I tried to use below code to disable the weak TLS version, such as TLSv1.1 
TLSv1 and SSLv3, only left TLSv1.2, but it does not work


{code:java}

JettyHttpComponent jettyComponent =
getContext().getComponent("jetty", JettyHttpComponent.class);
SslSelectChannelConnector sslConnector = new 
SslSelectChannelConnector();
SslContextFactory sslFactory = sslConnector.getSslContextFactory();
 ..

SSLContextParameters sslContextParameters = new SSLContextParameters();
SecureSocketProtocolsParameters secureSocketProtocols = new 
SecureSocketProtocolsParameters();
secureSocketProtocols.getSecureSocketProtocol().add("TLSv1.2");
sslContextParameters.setSecureSocketProtocols(secureSocketProtocols);

jettyComponent.setSslContextParameters(sslContextParameters);
jettyComponent.setSslSocketConnectors(connectors);
from("jetty:https://0.0.0.0:343/eastweb/;)
{code}

Could you help to have a support? thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11754) Apache Camel FTP getting Cannot retrieve file: RemoteFile error

[dheitzer (JIRA)]

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

dheitzer commented on CAMEL-11754:
--

Hi Claus, that sounds like a good plan, thanks very much for your time and 
input.  Yours also Önder Sezgin.  Thanks.

> Apache Camel FTP getting Cannot retrieve file: RemoteFile error
> ---
>
> Key: CAMEL-11754
> URL: https://issues.apache.org/jira/browse/CAMEL-11754
> Project: Camel
>  Issue Type: Bug
>  Components: camel-ftp
>Affects Versions: 2.19.0
> Environment: Windows 10 x64
> jdk1.8.0_131
> Camel 2.19.0
>Reporter: dheitzer
>
> I'm receiving an error from the FTP Component when its processing files in 
> Camel 2.19.0.
> I'm trying to retrieve files using the Camel FTP component (Camel 2.19.0):
> from("ftp://my.host.com:21/my/relative/directory?download=true=false=false;)
> {code:java}
> org.apache.camel.component.file.GenericFileOperationFailedException: Cannot 
> retrieve file: RemoteFile[my/relative/directory/file1.txt] from: 
> ftp://my.host.com:21/my/relative/directory?delete=false=true=false
> at 
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:427)
> at 
> org.apache.camel.component.file.remote.RemoteFileConsumer.processExchange(RemoteFileConsumer.java:137)
> at 
> org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:218)
> at 
> org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:182)
> at 
> org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:174)
> at 
> org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:101)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> From the TRACE logs, I can see that Camel is listing the files in the 
> directory correctly:
> {code:java}
> [TRACE] 2017-09-05 11:40:49,438 
> org.apache.camel.component.file.remote.FtpConsumer - Polling directory: 
> my/relative/directory
> [TRACE] 2017-09-05 11:40:51,748 
> org.apache.camel.component.file.remote.FtpOperations - 
> listFiles(my/relative/directory)
> [TRACE] 2017-09-05 11:40:58,657 
> org.apache.camel.component.file.remote.FtpConsumer - Found 3 in directory: 
> my/relative/directory
> [TRACE] 2017-09-05 11:40:58,657 
> org.apache.camel.component.file.remote.FtpConsumer - 
> FtpFile[name=/absolute/path/to/directory/file1.txt, dir=false, file=true]
> [TRACE] 2017-09-05 11:40:58,657 
> org.apache.camel.component.file.remote.FtpConsumer - 
> FtpFile[name=/absolute/path/to/directory/file2.txt, dir=false, file=true]
> [TRACE] 2017-09-05 11:40:58,657 
> org.apache.camel.component.file.remote.FtpConsumer - 
> FtpFile[name=/absolute/path/to/directory/file3.txt, dir=false, file=true]
> {code}
> When Camel tries to process each file however, it appears to be prepending 
> the relative directory to the absolute directory and failing to find the 
> resulting garbled path:
> {code:java}
> [TRACE] 2017-09-05 11:40:59,417 
> org.apache.camel.component.file.remote.FtpConsumer - Processing file: 
> RemoteFile[absolute/path/to/directory/file1.txt]
> [TRACE] 2017-09-05 11:40:59,418 
> org.apache.camel.component.file.remote.FtpConsumer - Retrieving file: 
> my/relative/directory//absolute/path/to/directory/file1.txt from: 
> ftp://my.host.com:21/my/relative/directory?delete=false=true=false
> [TRACE] 2017-09-05 11:40:59,418 
> org.apache.camel.component.file.remote.FtpOperations - 
> retrieveFile(my/relative/directory//absolute/path/to/directory/file1.txt)
> [TRACE] 2017-09-05 11:40:59,418 
> org.apache.camel.component.file.remote.FtpOperations - Client retrieveFile: 
> my/relative/directory//absolute/path/to/directory/file1.txt
> [WARN ] 2017-09-05 11:40:59,518 
> org.apache.camel.component.file.remote.FtpConsumer - Error processing file 
> RemoteFile[absolute/path/to/directory/file1.txt] due to Cannot retrieve file: 
> RemoteFile[absolute/path/to/directory/file1.txt] from: 
> ftp://my.host.com:21/my/relative/directory?delete=false=true=false
> {code}
> This path in the logs constructed by the FTPComponent is incorrect:
> {noformat}
> Retrieving file: 

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

[Martin Lichtin (JIRA)]

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

Martin Lichtin commented on CAMEL-10913:


Hi Nicola, would it be possible to make this change available for 2.18.x?
I seem to also run into this issue and unfortunately cannot upgrade to 2.19.

> 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
>Assignee: Nicola Ferraro
> Fix For: 2.19.0
>
>
> 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.4.14#64029)

[jira] [Commented] (CAMEL-11658) URISyntaxException in RestletProducer

[Anton Koscejev (JIRA)]

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

Anton Koscejev commented on CAMEL-11658:


I've submitted a unit test as a PR (see above). 

The regression is only for some characters (such as space). Other characters 
actually didn't work very well before (question mark "?" could cause other 
parts of path to become query, etc.).

> URISyntaxException in RestletProducer
> -
>
> Key: CAMEL-11658
> URL: https://issues.apache.org/jira/browse/CAMEL-11658
> Project: Camel
>  Issue Type: Bug
>  Components: camel-restlet
>Affects Versions: 2.19.0
>Reporter: Anton Koscejev
>
> CAMEL-10392 introduced session/cookie handling for camel-restlet. However, 
> this also introduced a bug where new URI is created from resourceUri before 
> it's encoded.
> Before this change the uri would be safely encoded within restlet's Request 
> constructor.
> See this code in RestletProducer:
> {code}
> String resourceUri = buildUri(endpoint, exchange);
> URI uri = new URI(resourceUri); // <- causes exception on 
> unencoded uri
> request = new Request(endpoint.getRestletMethod(), resourceUri); 
> // <- will encode uri
> binding.populateRestletRequestFromExchange(request, exchange);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11658) URISyntaxException in RestletProducer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-11658:


GitHub user koscejev opened a pull request:

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

CAMEL-11658: test for RestletProducer handling unencoded headers

This is just a unit test showing how a header with characters that are not 
allowed in URI path will cause a failure within RestletProducer.

CAMEL-11658: The regression is only for some characters (such as space). 
Other characters actually didn't work very well before (question mark "?" could 
cause other parts of path to become query, etc.).

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

$ git pull https://github.com/koscejev/camel CAMEL-11658

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

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


commit cd5f51ddb9d30aaa2161f6a11c1d45ea97d5978b
Author: Anton Koscejev 
Date:   2017-09-18T16:49:48Z

CAMEL-11658: test for RestletProducer handling unencoded headers




> URISyntaxException in RestletProducer
> -
>
> Key: CAMEL-11658
> URL: https://issues.apache.org/jira/browse/CAMEL-11658
> Project: Camel
>  Issue Type: Bug
>  Components: camel-restlet
>Affects Versions: 2.19.0
>Reporter: Anton Koscejev
>
> CAMEL-10392 introduced session/cookie handling for camel-restlet. However, 
> this also introduced a bug where new URI is created from resourceUri before 
> it's encoded.
> Before this change the uri would be safely encoded within restlet's Request 
> constructor.
> See this code in RestletProducer:
> {code}
> String resourceUri = buildUri(endpoint, exchange);
> URI uri = new URI(resourceUri); // <- causes exception on 
> unencoded uri
> request = new Request(endpoint.getRestletMethod(), resourceUri); 
> // <- will encode uri
> binding.populateRestletRequestFromExchange(request, exchange);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11782) Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved ref/idref to component:

[Christian Schneider (JIRA)]

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

Christian Schneider resolved CAMEL-11782.
-
Resolution: Fixed

> Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved 
> ref/idref to component: 
> ---
>
> Key: CAMEL-11782
> URL: https://issues.apache.org/jira/browse/CAMEL-11782
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.19.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 2.19.3
>
>
> java.lang.RuntimeException: Unresolved ref/idref to component: 
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.waitForBlueprintContainer(CamelBlueprintHelper.java:367)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:175)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: 
> Unresolved ref/idref to component: 
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)
>   at 
> org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
>   at 
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>   at 
> 

[jira] [Created] (CAMEL-11783) Updates to http://camel.apache.org/rest-dsl.html

[Martin Lichtin (JIRA)]

Martin Lichtin created CAMEL-11783:
--

 Summary: Updates to http://camel.apache.org/rest-dsl.html
 Key: CAMEL-11783
 URL: https://issues.apache.org/jira/browse/CAMEL-11783
 Project: Camel
  Issue Type: Improvement
Reporter: Martin Lichtin


The page http://camel.apache.org/rest-dsl.html is a bit out of date.
Specifically, "corsHeaderProperty" is now called "corsHeaders".
Also there's a new "apiProperty" not yet documented.

In addition it'd be good to clarify that for PUT and POST, the request body 
will by default be also the HTTP response. It's sort of normal with Camel, but 
not what one would expect when using the Rest DSL. Might want to show an 
example of how to empty the body for a .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11781) Support BoxUser.moveFolderToUser in camel-box

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-11781:


Github user fjollberg closed the pull request at:

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


> Support BoxUser.moveFolderToUser in camel-box
> -
>
> Key: CAMEL-11781
> URL: https://issues.apache.org/jira/browse/CAMEL-11781
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-box
>Affects Versions: 2.19.2
>Reporter: Fredrik Jönsson
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> We are currently implementing an Box enterprise account integration using 
> camel-box. When deleting accounts we need support for the 
> BoxUser.moveFolderToUser in camel-box in order to transfer the data of the 
> account elsewhere before deletion, similar to how the Box user interface 
> works when deleting users.
> I'll register a GitHub pull-request with a suggested implementation shortly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11782) Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved ref/idref to component:

[Christian Schneider (JIRA)]

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

Christian Schneider edited comment on CAMEL-11782 at 9/18/17 2:55 PM:
--

I was able to track down the error to this bean:
  






 
  

The issue is ref bean= 
this is not correct for blueprint. It must be ref component-id=...

I will fix this.



was (Author: ch...@die-schneider.net):
I was able to track down the error to this bean:
  






 
  

When I remove the 


the test works again. So it seems there is a bug in the CXF cluster-strategy 
blueprint bean.
I will open an issue at CXF and track it there. 

Until then commenting out the cxf:cluster-strategy is w workaround.

> Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved 
> ref/idref to component: 
> ---
>
> Key: CAMEL-11782
> URL: https://issues.apache.org/jira/browse/CAMEL-11782
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.19.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 2.19.3
>
>
> java.lang.RuntimeException: Unresolved ref/idref to component: 
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.waitForBlueprintContainer(CamelBlueprintHelper.java:367)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:175)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: 
> Unresolved ref/idref to component: 
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)
>   at 
> org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)
>   at 
> 

[jira] [Commented] (CAMEL-11782) Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved ref/idref to component:

[Christian Schneider (JIRA)]

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

Christian Schneider commented on CAMEL-11782:
-

I was able to track down the error to this bean:
  






 
  

When I remove the 


the test works again. So it seems there is a bug in the CXF cluster-strategy 
blueprint bean.
I will open an issue at CXF and track it there. 

Until then commenting out the cxf:cluster-strategy is w workaround.

> Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved 
> ref/idref to component: 
> ---
>
> Key: CAMEL-11782
> URL: https://issues.apache.org/jira/browse/CAMEL-11782
> Project: Camel
>  Issue Type: Bug
>  Components: camel-cxf
>Affects Versions: 2.19.2
>Reporter: Christian Schneider
>Assignee: Christian Schneider
> Fix For: 2.19.3
>
>
> java.lang.RuntimeException: Unresolved ref/idref to component: 
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.waitForBlueprintContainer(CamelBlueprintHelper.java:367)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:175)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: 
> Unresolved ref/idref to component: 
>   at 
> org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)
>   at 
> org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)
>   at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
>   at 

[jira] [Created] (CAMEL-11782) Test failure in CxfEndpointBeansTest after update to CXF 3.2.0: Unresolved ref/idref to component:

[Christian Schneider (JIRA)]

Christian Schneider created CAMEL-11782:
---

 Summary: Test failure in CxfEndpointBeansTest after update to CXF 
3.2.0: Unresolved ref/idref to component: 
 Key: CAMEL-11782
 URL: https://issues.apache.org/jira/browse/CAMEL-11782
 Project: Camel
  Issue Type: Bug
  Components: camel-cxf
Affects Versions: 2.19.2
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: 2.19.3


java.lang.RuntimeException: Unresolved ref/idref to component: 
at 
org.apache.camel.test.blueprint.CamelBlueprintHelper.waitForBlueprintContainer(CamelBlueprintHelper.java:367)
at 
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:175)
at 
org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.osgi.service.blueprint.container.ComponentDefinitionException: 
Unresolved ref/idref to component: 
at 
org.apache.aries.blueprint.container.BlueprintRepository.validate(BlueprintRepository.java:262)
at 
org.apache.aries.blueprint.container.RecipeBuilder.createRepository(RecipeBuilder.java:96)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.getRepository(BlueprintContainerImpl.java:481)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:328)
at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
at 
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 

[jira] [Work started] (CAMEL-11684) HealthCheck : expose health check info through JMX

[Luca Burgazzoli (JIRA)]

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

Work on CAMEL-11684 started by Luca Burgazzoli.
---
> HealthCheck : expose health check info through JMX
> --
>
> Key: CAMEL-11684
> URL: https://issues.apache.org/jira/browse/CAMEL-11684
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Reporter: Luca Burgazzoli
>Assignee: Luca Burgazzoli
>  Labels: health-check
> Fix For: 2.20.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11781) Support BoxUser.moveFolderToUser in camel-box

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11781.
-
   Resolution: Fixed
 Assignee: Claus Ibsen
Fix Version/s: 2.20.0

Thanks for the PR

> Support BoxUser.moveFolderToUser in camel-box
> -
>
> Key: CAMEL-11781
> URL: https://issues.apache.org/jira/browse/CAMEL-11781
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-box
>Affects Versions: 2.19.2
>Reporter: Fredrik Jönsson
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> We are currently implementing an Box enterprise account integration using 
> camel-box. When deleting accounts we need support for the 
> BoxUser.moveFolderToUser in camel-box in order to transfer the data of the 
> account elsewhere before deletion, similar to how the Box user interface 
> works when deleting users.
> I'll register a GitHub pull-request with a suggested implementation shortly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (CAMEL-11779) camel-facebook should not transitively depend on spi-annotations

[Claus Ibsen (JIRA)]

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

Claus Ibsen reopened CAMEL-11779:
-

> camel-facebook should not transitively depend on spi-annotations
> 
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11779) camel-facebook should not transitively depend on spi-annotations

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11779.
-
Resolution: Fixed

Thanks yeah that is a mistake, just fixed.

> camel-facebook should not transitively depend on spi-annotations
> 
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11780) camel-amqp - SSL Transport configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-11780:
-

We love contributions, so try to help out with the qpid upgrade
http://camel.apache.org/contributing

> camel-amqp - SSL Transport configuration
> 
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
> Fix For: 2.21.0
>
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11780) camel-amqp - SSL Transport configuration

[Cyril EDME (JIRA)]

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

Cyril EDME commented on CAMEL-11780:


Great, thanks for the quick answer.
Do you have an idea of the schedule on a such task ? If not please let me, our 
team is eager about this improvement.

Thanks

> camel-amqp - SSL Transport configuration
> 
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
> Fix For: 2.21.0
>
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11147) camel-jms2 - JMS component using JMS 2.x api

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11147.
-
Resolution: Fixed

And there is a tests/camel-itest-jms2 that does some JMS 2.0 testing with 
Artemis broker

> camel-jms2 - JMS component using JMS 2.x api
> 
>
> Key: CAMEL-11147
> URL: https://issues.apache.org/jira/browse/CAMEL-11147
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-jms
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> The camel-sjms2 is extending camel-sjms but adding JMS 2.0 api and use that 
> such as shared topic.
> We should look at the camel-jms component and do a camel-jms2 that is using 
> the JMS 2.0 api (requires artemis for testing, as AMQ is not 2.0). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11147) camel-jms2 - JMS component using JMS 2.x api

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-11147:
-

Okay so we found a way to make camel-jms compatible and support both JMS 1.1 
and 2.0. So we have just added the new JMS 2.0 options to the 
component/endpoint.

> camel-jms2 - JMS component using JMS 2.x api
> 
>
> Key: CAMEL-11147
> URL: https://issues.apache.org/jira/browse/CAMEL-11147
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-jms
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> The camel-sjms2 is extending camel-sjms but adding JMS 2.0 api and use that 
> such as shared topic.
> We should look at the camel-jms component and do a camel-jms2 that is using 
> the JMS 2.0 api (requires artemis for testing, as AMQ is not 2.0). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11779) camel-facebook should not transitively depend on spi-annotations

[Hendy Irawan (JIRA)]

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

Hendy Irawan updated CAMEL-11779:
-
Summary: camel-facebook should not transitively depend on spi-annotations  
(was: spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping 
classes)

> camel-facebook should not transitively depend on spi-annotations
> 
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11779) camel-facebook should not transitively depend on spi-annotations

[Hendy Irawan (JIRA)]

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

Hendy Irawan updated CAMEL-11779:
-
Component/s: (was: camel-core)
 camel-facebook

> camel-facebook should not transitively depend on spi-annotations
> 
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-facebook
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11781) Support BoxUser.moveFolderToUser in camel-box

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-11781:


GitHub user fjollberg opened a pull request:

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

CAMEL-11781: Support for BoxUser.moveFolderToUser in camel-box.

Add support for BoxUser.moveFolderToUser in order to be able to move data 
from a user account into another before deleting an enterprise user as in the 
Box user interface.

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

$ git pull https://github.com/fjollberg/camel 
camel-box-implement-movefoldertouser

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

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


commit 26d2913d2fb0dfc35d44072dab0107862ee45892
Author: Fredrik Jönsson 
Date:   2017-09-18T12:10:13Z

CAMEL-11781: Support for BoxUser.moveFolderToUser in camel-box.




> Support BoxUser.moveFolderToUser in camel-box
> -
>
> Key: CAMEL-11781
> URL: https://issues.apache.org/jira/browse/CAMEL-11781
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-box
>Affects Versions: 2.19.2
>Reporter: Fredrik Jönsson
>
> We are currently implementing an Box enterprise account integration using 
> camel-box. When deleting accounts we need support for the 
> BoxUser.moveFolderToUser in camel-box in order to transfer the data of the 
> account elsewhere before deletion, similar to how the Box user interface 
> works when deleting users.
> I'll register a GitHub pull-request with a suggested implementation shortly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Hendy Irawan (JIRA)]

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

Hendy Irawan commented on CAMEL-11779:
--

Aha, I think I found it :

{noformat}
[INFO] +- org.apache.camel:camel-core:jar:2.19.3:compile
[INFO] |  +- com.sun.xml.bind:jaxb-core:jar:2.2.11:compile
[INFO] |  \- com.sun.xml.bind:jaxb-impl:jar:2.2.11:compile
[INFO] +- org.apache.camel:camel-spring-javaconfig:jar:2.19.3:compile
[INFO] |  +- org.apache.camel:camel-spring:jar:2.19.3:compile
[INFO] |  |  +- org.springframework:spring-aop:jar:4.3.11.RELEASE:compile
[INFO] |  |  +- org.springframework:spring-context:jar:4.3.11.RELEASE:compile
[INFO] |  |  +- org.springframework:spring-beans:jar:4.3.11.RELEASE:compile
[INFO] |  |  \- org.springframework:spring-expression:jar:4.3.11.RELEASE:compile
[INFO] |  \- 
org.apache.servicemix.bundles:org.apache.servicemix.bundles.cglib:jar:3.2.4_1:compile
[INFO] +- org.apache.camel:camel-rss:jar:2.19.3:compile
[INFO] |  +- org.apache.camel:camel-atom:jar:2.19.3:compile
[INFO] |  |  +- commons-codec:commons-codec:jar:1.10:compile
[INFO] |  |  +- org.apache.abdera:abdera-core:jar:1.1.3:compile
[INFO] |  |  |  +- org.apache.abdera:abdera-i18n:jar:1.1.3:compile
[INFO] |  |  |  \- 
org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.1:compile
[INFO] |  |  +- org.apache.abdera:abdera-parser:jar:1.1.3:compile
[INFO] |  |  |  +- 
org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile
[INFO] |  |  |  \- jaxen:jaxen:jar:1.1.6:compile
[INFO] |  |  +- org.apache.ws.commons.axiom:axiom-api:jar:1.2.14:compile
[INFO] |  |  |  \- org.apache.james:apache-mime4j-core:jar:0.7.2:compile
[INFO] |  |  \- org.apache.ws.commons.axiom:axiom-impl:jar:1.2.14:compile
[INFO] |  | \- org.codehaus.woodstox:woodstox-core-asl:jar:4.1.4:compile
[INFO] |  |\- org.codehaus.woodstox:stax2-api:jar:3.1.1:compile
[INFO] |  \- rome:rome:jar:1.0:compile
[INFO] | \- jdom:jdom:jar:1.0:compile
[INFO] +- org.apache.camel:camel-facebook:jar:2.19.3:compile
[INFO] |  +- org.apache.camel:spi-annotations:jar:2.19.3:compile
[INFO] |  \- org.facebook4j:facebook4j-core:jar:2.4.8:compile
[INFO] +- org.apache.camel:camel-spring-boot-starter:jar:2.19.3:compile
[INFO] |  +- 
org.springframework.boot:spring-boot-starter:jar:1.5.7.RELEASE:compile
[INFO] |  |  +- org.springframework.boot:spring-boot:jar:1.5.7.RELEASE:compile
[INFO] |  |  +- 
org.springframework.boot:spring-boot-autoconfigure:jar:1.5.7.RELEASE:compile
[INFO] |  |  \- 
org.springframework.boot:spring-boot-starter-logging:jar:1.5.7.RELEASE:compile
[INFO] |  | \- org.slf4j:log4j-over-slf4j:jar:1.7.25:compile
[INFO] |  +- org.apache.camel:camel-spring-boot:jar:2.19.3:compile
[INFO] |  \- org.apache.camel:camel-core-starter:jar:2.19.3:compile
[INFO] | \- com.github.ben-manes.caffeine:caffeine:jar:2.3.5:compile
[INFO] +- org.apache.camel:camel-test-spring:jar:2.19.3:test
[INFO] |  +- org.apache.camel:camel-test:jar:2.19.3:test
[INFO] |  \- org.springframework:spring-test:jar:4.3.11.RELEASE:test
{noformat}

I think the bug is in camel-facebook's pom. I don't see spi-annotations 
depended by other camel artifacts.

> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-10109) Camel Spring Boot does not load EventNotifiers

[Muthukannan Kanniappan (JIRA)]

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

Muthukannan Kanniappan commented on CAMEL-10109:


This issue is marked as resolved but I still continue to face it in Camel 
2.18.3. Currently I have made it to work using 
{code:java}
context.getManagementStrategy().addEventNotifier()
{code}
 not as spring Component/Bean. 

> Camel Spring Boot does not load EventNotifiers
> --
>
> Key: CAMEL-10109
> URL: https://issues.apache.org/jira/browse/CAMEL-10109
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-spring-boot
>Affects Versions: 2.17.1
>Reporter: John Mark
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.18.0
>
>
> When using the camel spring XML, {{EventNotifier}} objects in the Spring 
> context are automatically detected and used by the camel context. This is not 
> the case when using camel-spring-boot, but it should be.
> See 
> http://camel.apache.org/eventnotifier-to-log-details-about-all-sent-exchanges.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11781) Support BoxUser.moveFolderToUser in camel-box

[JIRA]

Fredrik Jönsson created CAMEL-11781:
---

 Summary: Support BoxUser.moveFolderToUser in camel-box
 Key: CAMEL-11781
 URL: https://issues.apache.org/jira/browse/CAMEL-11781
 Project: Camel
  Issue Type: Improvement
  Components: camel-box
Affects Versions: 2.19.2
Reporter: Fredrik Jönsson


We are currently implementing an Box enterprise account integration using 
camel-box. When deleting accounts we need support for the 
BoxUser.moveFolderToUser in camel-box in order to transfer the data of the 
account elsewhere before deletion, similar to how the Box user interface works 
when deleting users.

I'll register a GitHub pull-request with a suggested implementation shortly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-11779:
-

They are not transitive, look at the pom on maven central
https://repo1.maven.org/maven2/org/apache/camel/camel-core/2.19.3/camel-core-2.19.3.pom

And the maven tree of an example is

{code}
davsclaus:/Users/davsclaus/workspace/camel/examples/camel-example-console 
(master)/$ mvn dependency:tree
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Camel :: Example :: Console 2.20.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @ 
camel-example-console ---
[INFO] org.apache.camel.example:camel-example-console:jar:2.20.0-SNAPSHOT
[INFO] +- org.apache.camel:camel-core:jar:2.20.0-SNAPSHOT:compile
[INFO] |  \- org.slf4j:slf4j-api:jar:1.7.22:compile
[INFO] +- org.apache.camel:camel-spring:jar:2.20.0-SNAPSHOT:compile
[INFO] |  +- org.springframework:spring-core:jar:4.3.11.RELEASE:compile
[INFO] |  |  \- commons-logging:commons-logging:jar:1.2:compile
[INFO] |  +- org.springframework:spring-aop:jar:4.3.11.RELEASE:compile
[INFO] |  +- org.springframework:spring-context:jar:4.3.11.RELEASE:compile
[INFO] |  +- org.springframework:spring-beans:jar:4.3.11.RELEASE:compile
[INFO] |  +- org.springframework:spring-expression:jar:4.3.11.RELEASE:compile
[INFO] |  \- org.springframework:spring-tx:jar:4.3.11.RELEASE:compile
[INFO] +- org.apache.camel:camel-stream:jar:2.20.0-SNAPSHOT:compile
[INFO] +- org.apache.logging.log4j:log4j-api:jar:2.8.2:runtime
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.8.2:runtime
[INFO] +- org.apache.logging.log4j:log4j-slf4j-impl:jar:2.8.2:runtime
[INFO] +- com.sun.xml.bind:jaxb-core:jar:2.2.11:compile
[INFO] \- com.sun.xml.bind:jaxb-impl:jar:2.2.11:compile
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
{code}


> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Hendy Irawan (JIRA)]

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

Hendy Irawan commented on CAMEL-11779:
--

But if that's also true, why end applications need to depend on spi-annotations 
?

You should mark it, say, optional=true. So that camel-core can still depend on 
it but does not make it transitive to the users (apps) of camel.

> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-11779:
-

No we shade/copy them in

> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Hendy Irawan (JIRA)]

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

Hendy Irawan commented on CAMEL-11779:
--

But wait, if that is true then the classes should not be in camel-core, right? 
Since it depends on spi-annotations anyway.

> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11775) Upgrade to Spring Boot 1.5.7 or better

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11775.
-
Resolution: Fixed
  Assignee: Claus Ibsen

> Upgrade to Spring Boot 1.5.7 or better
> --
>
> Key: CAMEL-11775
> URL: https://issues.apache.org/jira/browse/CAMEL-11775
> Project: Camel
>  Issue Type: Task
>  Components: camel-spring-boot
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.1
>
>
> There is a issue with downloading 1.5.7 from maven central for people, so we 
> have reverted the upgrade.
> When maven is okay again we can revert the commits so we are upgrading.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-9799) JSON/JSON Schema validator

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-9799:


We do prefer maven central and try to avoid 3rd party maven repositories as 
they are more unreliable and causes more problem with building.

However it seems jitpack is a general purpose maven repo, and not a single 
company own repo so that seems okay in my eyes.

> JSON/JSON Schema validator
> --
>
> Key: CAMEL-9799
> URL: https://issues.apache.org/jira/browse/CAMEL-9799
> Project: Camel
>  Issue Type: New Feature
>Reporter: Andreas Gebhardt
> Fix For: Future
>
>
> > Von: Gnanaguru S
> > An: ★ d...@camel.apache.org
> >
> > Subject: \[DISCUSS\] - Thoughts on Apache Camel 2.18 and towards 3.0
> >
> > \[...\]
> > 7.  JSON validator. XML XSD validation is nice and straight forward, but it
> > will be great if we have something similar for JSON as well. like
> > to:json-validator:classpath/response.json
> > \[...\]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11778) New camel-ldif component

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11778:

Fix Version/s: 2.20.0

> New camel-ldif component
> 
>
> Key: CAMEL-11778
> URL: https://issues.apache.org/jira/browse/CAMEL-11778
> Project: Camel
>  Issue Type: New Feature
>Reporter: Tim Hurman
>  Labels: patch
> Fix For: 2.20.0
>
> Attachments: camel-ldif.diff
>
>
> I've created a new component to process LDIF files. This is to process update 
> changes to LDAP servers. I've attached a diff file against the Camel git 
> repository.
> Please let me know if this is okay or any changes need to be made. I'm happy 
> to fix them up.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CAMEL-11779) spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes

[Claus Ibsen (JIRA)]

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

Claus Ibsen resolved CAMEL-11779.
-
   Resolution: Not A Problem
 Assignee: Claus Ibsen
Fix Version/s: 2.20.0

This is by design where those spi annotations are built first before camel-core

> spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 overlapping classes
> --
>
> Key: CAMEL-11779
> URL: https://issues.apache.org/jira/browse/CAMEL-11779
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.19.3
>Reporter: Hendy Irawan
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.20.0
>
>
> {noformat}
> [WARNING] spi-annotations-2.19.3.jar, camel-core-2.19.3.jar define 7 
> overlapping classes: 
> [WARNING]   - org.apache.camel.spi.UriParam
> [WARNING]   - org.apache.camel.spi.UriEndpoint
> [WARNING]   - org.apache.camel.spi.UriParams
> [WARNING]   - org.apache.camel.spi.UriPath
> [WARNING]   - org.apache.camel.spi.AsPredicate
> [WARNING]   - org.apache.camel.spi.AsEndpointUri
> [WARNING]   - org.apache.camel.spi.Metadata
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> {noformat}
> While harmless, it'd be appreciated if there's no duplication, so there's no 
> warning and saves space (in unshaded builds).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11780) camel-amqp - SSL Transport configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11780:

Summary: camel-amqp - SSL Transport configuration  (was: SSL Transport 
configuration)

> camel-amqp - SSL Transport configuration
> 
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
> Fix For: 2.21.0
>
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11777) Transactional hazelcast:seda component uses not transaction aware queue

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11777:

Issue Type: Improvement  (was: Bug)

> Transactional hazelcast:seda component uses not transaction aware queue
> ---
>
> Key: CAMEL-11777
> URL: https://issues.apache.org/jira/browse/CAMEL-11777
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Affects Versions: 2.19.2
>Reporter: Kirill Merkushev
> Fix For: 2.20.0
>
>
> As mentioned in docs 
> http://docs.hazelcast.org/docs/3.8.4/manual/html-single/index.html#creating-a-transaction-interface
> Data structures should be transaction-aware and initialized inside of 
> transaction context. Now hazelcast seda component uses queue initialized 
> externally for the transaction. So when we rollback transaction - things stay 
> the same like we already committed changes (this simply noop).
> Patch should look like (but exactly this version fails tests, so I should 
> investigate more)
> {code:none}
> index 7e3b24cc8f..cebd69ce16 100644
> --- 
> a/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> +++ 
> b/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> @@ -16,10 +16,10 @@
>   */
>  package org.apache.camel.component.hazelcast.seda;
>  
> -import java.util.concurrent.BlockingQueue;
>  import java.util.concurrent.ExecutorService;
>  import java.util.concurrent.TimeUnit;
>  
> +import com.hazelcast.core.BaseQueue;
>  import com.hazelcast.transaction.TransactionContext;
>  
>  import org.apache.camel.AsyncCallback;
> @@ -71,7 +71,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  }
>  
>  public void run() {
> -final BlockingQueue queue = endpoint.getQueue();
> +BaseQueue queue = 
> endpoint.getHazelcastInstance().getQueue(endpoint.getConfiguration().getQueueName());
>  
>  while (queue != null && isRunAllowed()) {
>  final Exchange exchange = this.getEndpoint().createExchange();
> @@ -85,6 +85,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  if (transactionCtx != null) {
>  log.trace("Begin transaction: {}", 
> transactionCtx.getTxnId());
>  transactionCtx.beginTransaction();
> +queue = 
> transactionCtx.getQueue(endpoint.getConfiguration().getQueueName());
>  }
>  }
>  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11780) camel-amqp - SSL Transport configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11780:

Fix Version/s: 2.21.0

> camel-amqp - SSL Transport configuration
> 
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
> Fix For: 2.21.0
>
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11777) Transactional hazelcast:seda component uses not transaction aware queue

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11777:

Fix Version/s: 2.20.0

> Transactional hazelcast:seda component uses not transaction aware queue
> ---
>
> Key: CAMEL-11777
> URL: https://issues.apache.org/jira/browse/CAMEL-11777
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-hazelcast
>Affects Versions: 2.19.2
>Reporter: Kirill Merkushev
> Fix For: 2.20.0
>
>
> As mentioned in docs 
> http://docs.hazelcast.org/docs/3.8.4/manual/html-single/index.html#creating-a-transaction-interface
> Data structures should be transaction-aware and initialized inside of 
> transaction context. Now hazelcast seda component uses queue initialized 
> externally for the transaction. So when we rollback transaction - things stay 
> the same like we already committed changes (this simply noop).
> Patch should look like (but exactly this version fails tests, so I should 
> investigate more)
> {code:none}
> index 7e3b24cc8f..cebd69ce16 100644
> --- 
> a/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> +++ 
> b/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> @@ -16,10 +16,10 @@
>   */
>  package org.apache.camel.component.hazelcast.seda;
>  
> -import java.util.concurrent.BlockingQueue;
>  import java.util.concurrent.ExecutorService;
>  import java.util.concurrent.TimeUnit;
>  
> +import com.hazelcast.core.BaseQueue;
>  import com.hazelcast.transaction.TransactionContext;
>  
>  import org.apache.camel.AsyncCallback;
> @@ -71,7 +71,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  }
>  
>  public void run() {
> -final BlockingQueue queue = endpoint.getQueue();
> +BaseQueue queue = 
> endpoint.getHazelcastInstance().getQueue(endpoint.getConfiguration().getQueueName());
>  
>  while (queue != null && isRunAllowed()) {
>  final Exchange exchange = this.getEndpoint().createExchange();
> @@ -85,6 +85,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  if (transactionCtx != null) {
>  log.trace("Begin transaction: {}", 
> transactionCtx.getTxnId());
>  transactionCtx.beginTransaction();
> +queue = 
> transactionCtx.getQueue(endpoint.getConfiguration().getQueueName());
>  }
>  }
>  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11780) camel-amqp - SSL Transport configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen commented on CAMEL-11780:
-

We should look at upgrading qpid

> camel-amqp - SSL Transport configuration
> 
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
> Fix For: 2.21.0
>
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11780) SSL Transport configuration

[Claus Ibsen (JIRA)]

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

Claus Ibsen updated CAMEL-11780:

Issue Type: Improvement  (was: Bug)

> SSL Transport configuration
> ---
>
> Key: CAMEL-11780
> URL: https://issues.apache.org/jira/browse/CAMEL-11780
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-amqp
>Affects Versions: 2.19.2
>Reporter: Cyril EDME
>
> Hi,
> i'm using camel and specially the amqp component to consume a topic. 
> Everything is working well but I'm confused regarding the SSL configuration.
> It's not clear in the documentation, I don't want to use the default JVM 
> certificate storage so I tried to configure the connection factory with the 
> [qpid 
> documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
>  but the qpid-jms-client version used by amqp component (0.11.1) doesn't 
> handle the amqps schema URI.
> There is another way to configure the SSL transport like the key store 
> location and password without a qpid upgrade ?
> Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11777) Transactional hazelcast:seda component uses not transaction aware queue

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CAMEL-11777:


GitHub user lanwen opened a pull request:

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

CAMEL-11777: Use transaction aware queue in hazelcast:seda component

As mentioned in docs of hz (any version, current for example)

http://docs.hazelcast.org/docs/3.8.4/manual/html-single/index.html#creating-a-transaction-interface
Transaction do its work if queue initialized with help of transaction ctx

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

$ git pull https://github.com/lanwen/camel CAMEL-11777

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

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


commit c679eaf67acb129137b04b8199c4ddbafa5b28b5
Author: Kirill Merkushev 
Date:   2017-09-18T09:13:49Z

CAMEL-11777: Use transaction aware queue in hazelcast:seda component

As mentioned in docs of hz (any version, current for example)

http://docs.hazelcast.org/docs/3.8.4/manual/html-single/index.html#creating-a-transaction-interface
Transaction do its work if queue initialized with help of transaction ctx




> Transactional hazelcast:seda component uses not transaction aware queue
> ---
>
> Key: CAMEL-11777
> URL: https://issues.apache.org/jira/browse/CAMEL-11777
> Project: Camel
>  Issue Type: Bug
>  Components: camel-hazelcast
>Affects Versions: 2.19.2
>Reporter: Kirill Merkushev
>
> As mentioned in docs 
> http://docs.hazelcast.org/docs/3.8.4/manual/html-single/index.html#creating-a-transaction-interface
> Data structures should be transaction-aware and initialized inside of 
> transaction context. Now hazelcast seda component uses queue initialized 
> externally for the transaction. So when we rollback transaction - things stay 
> the same like we already committed changes (this simply noop).
> Patch should look like (but exactly this version fails tests, so I should 
> investigate more)
> {code:none}
> index 7e3b24cc8f..cebd69ce16 100644
> --- 
> a/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> +++ 
> b/components/camel-hazelcast/src/main/java/org/apache/camel/component/hazelcast/seda/HazelcastSedaConsumer.java
> @@ -16,10 +16,10 @@
>   */
>  package org.apache.camel.component.hazelcast.seda;
>  
> -import java.util.concurrent.BlockingQueue;
>  import java.util.concurrent.ExecutorService;
>  import java.util.concurrent.TimeUnit;
>  
> +import com.hazelcast.core.BaseQueue;
>  import com.hazelcast.transaction.TransactionContext;
>  
>  import org.apache.camel.AsyncCallback;
> @@ -71,7 +71,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  }
>  
>  public void run() {
> -final BlockingQueue queue = endpoint.getQueue();
> +BaseQueue queue = 
> endpoint.getHazelcastInstance().getQueue(endpoint.getConfiguration().getQueueName());
>  
>  while (queue != null && isRunAllowed()) {
>  final Exchange exchange = this.getEndpoint().createExchange();
> @@ -85,6 +85,7 @@ public class HazelcastSedaConsumer extends DefaultConsumer 
> implements Runnable {
>  if (transactionCtx != null) {
>  log.trace("Begin transaction: {}", 
> transactionCtx.getTxnId());
>  transactionCtx.beginTransaction();
> +queue = 
> transactionCtx.getQueue(endpoint.getConfiguration().getQueueName());
>  }
>  }
>  
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-11780) SSL Transport configuration

[Cyril EDME (JIRA)]

Cyril EDME created CAMEL-11780:
--

 Summary: SSL Transport configuration
 Key: CAMEL-11780
 URL: https://issues.apache.org/jira/browse/CAMEL-11780
 Project: Camel
  Issue Type: Bug
  Components: camel-amqp
Affects Versions: 2.19.2
Reporter: Cyril EDME


Hi,

i'm using camel and specially the amqp component to consume a topic. Everything 
is working well but I'm confused regarding the SSL configuration.
It's not clear in the documentation, I don't want to use the default JVM 
certificate storage so I tried to configure the connection factory with the 
[qpid 
documentation|https://qpid.apache.org/releases/qpid-jms-0.24.0/docs/index.html#ssl-transport-configuration-options]
 but the qpid-jms-client version used by amqp component (0.11.1) doesn't handle 
the amqps schema URI.

There is another way to configure the SSL transport like the key store location 
and password without a qpid upgrade ?

Thanks !



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)