[jira] [Updated] (CAMEL-11848) Using MongoDB Tailable Cursor Consumer on non-capped collection results in NullPointerException (instead of proper error message)
[ https://issues.apache.org/jira/browse/CAMEL-11848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Wein updated CAMEL-11848: --- Summary: Using MongoDB Tailable Cursor Consumer on non-capped collection results in NullPointerException (instead of proper error message) (was: Using MongoDB Tailable Cursor Consumer on non-capped collection results in NullPointerException (except of proper error message)) > Using MongoDB Tailable Cursor Consumer on non-capped collection results in > NullPointerException (instead of proper error message) > - > > Key: CAMEL-11848 > URL: https://issues.apache.org/jira/browse/CAMEL-11848 > Project: Camel > Issue Type: Bug >Reporter: Frank Wein >Priority: Minor > > When using the Camel MongoDB component with a tailable cursor consumer on a > non-capped collection, you get a NullPointerException (also see > http://camel.apache.org/mongodb.html#MongoDB-TailableCursorConsumer on this). > While using this feature on a non-capped collection is not supported, the > error message should be better (at the moment it only throws a > NullPointerException because the code tries to unbox a null in a Boolean > object). The code actually already has a better error message, but there is a > small logic flaw that prevents the error message from showing up. See > https://github.com/apache/camel/blob/camel-2.19.3/components/camel-mongodb/src/main/java/org/apache/camel/component/mongodb/MongoDbTailingProcess.java#L78 > for the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11848) Using MongoDB Tailable Cursor Consumer on non-capped collection results in NullPointerException (except of proper error message)
Frank Wein created CAMEL-11848: -- Summary: Using MongoDB Tailable Cursor Consumer on non-capped collection results in NullPointerException (except of proper error message) Key: CAMEL-11848 URL: https://issues.apache.org/jira/browse/CAMEL-11848 Project: Camel Issue Type: Bug Reporter: Frank Wein Priority: Minor When using the Camel MongoDB component with a tailable cursor consumer on a non-capped collection, you get a NullPointerException (also see http://camel.apache.org/mongodb.html#MongoDB-TailableCursorConsumer on this). While using this feature on a non-capped collection is not supported, the error message should be better (at the moment it only throws a NullPointerException because the code tries to unbox a null in a Boolean object). The code actually already has a better error message, but there is a small logic flaw that prevents the error message from showing up. See https://github.com/apache/camel/blob/camel-2.19.3/components/camel-mongodb/src/main/java/org/apache/camel/component/mongodb/MongoDbTailingProcess.java#L78 for the code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11847) cluster-service : support multiple cluster services
Luca Burgazzoli created CAMEL-11847: --- Summary: cluster-service : support multiple cluster services Key: CAMEL-11847 URL: https://issues.apache.org/jira/browse/CAMEL-11847 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.20.0 Reporter: Luca Burgazzoli Assignee: Luca Burgazzoli Fix For: 2.21.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11819) camel-velocity - Upgrade to 2.x
[ https://issues.apache.org/jira/browse/CAMEL-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181018#comment-16181018 ] ASF GitHub Bot commented on CAMEL-11819: GitHub user ramu11 opened a pull request: https://github.com/apache/camel/pull/1964 CAMEL-11819:camel-velocity - Upgrade to 2.x CAMEL-11819:camel-velocity - Upgrade to 2.x You can merge this pull request into a Git repository by running: $ git pull https://github.com/ramu11/camel master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1964.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 #1964 commit e375dd6e0b6e609e4ab85f8bec8511a11394c61d Author: Ramu Date: 2017-09-26T16:06:45Z CAMEL-11819:camel-velocity - Upgrade to 2.x > camel-velocity - Upgrade to 2.x > --- > > Key: CAMEL-11819 > URL: https://issues.apache.org/jira/browse/CAMEL-11819 > Project: Camel > Issue Type: Improvement > Components: camel-velocity >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > There is a 2.0 release - the old 1.7 release is very old. > Contributions is welcome > http://camel.apache.org/contributing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11819) camel-velocity - Upgrade to 2.x
[ https://issues.apache.org/jira/browse/CAMEL-11819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180922#comment-16180922 ] Ramu kakarla commented on CAMEL-11819: --- I am working on it > camel-velocity - Upgrade to 2.x > --- > > Key: CAMEL-11819 > URL: https://issues.apache.org/jira/browse/CAMEL-11819 > Project: Camel > Issue Type: Improvement > Components: camel-velocity >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > There is a 2.0 release - the old 1.7 release is very old. > Contributions is welcome > http://camel.apache.org/contributing -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180910#comment-16180910
]
ASF GitHub Bot commented on CAMEL-11842:
Github user jamesnetherton closed the pull request at:
https://github.com/apache/camel/pull/1963
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>Assignee: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11825) [example] etl - unable to resolve dependency on karaf
[
https://issues.apache.org/jira/browse/CAMEL-11825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11825.
-
Resolution: Fixed
Assignee: Claus Ibsen
Removed this old clunky example
> [example] etl - unable to resolve dependency on karaf
> -
>
> Key: CAMEL-11825
> URL: https://issues.apache.org/jira/browse/CAMEL-11825
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> {code}
> karaf@root()> feature:repo-add camel 2.20.0-SNAPSHOT
>
> Adding feature url
> mvn:org.apache.camel.karaf/apache-camel/2.20.0-SNAPSHOT/xml/features
> karaf@root()> feature:install camel
> karaf@root()> feature:repo-add
> mvn:org.apache.camel.example/camel-example-etl/2.20.0-SNAPSHOT/xml/features
> Adding feature url
> mvn:org.apache.camel.example/camel-example-etl/2.20.0-SNAPSHOT/xml/features
> karaf@root()> feature:install camel-example-etl
> Error executing command: Unable to resolve root: missing requirement [root]
> osgi.identity; osgi.identity=camel-example-etl; type=karaf.feature;
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]";
> filter:="(&(osgi.identity=camel-example-etl)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
> [caused by: Unable to resolve camel-example-etl/2.20.0.SNAPSHOT: missing
> requirement [camel-example-etl/2.20.0.SNAPSHOT] osgi.identity;
> osgi.identity=camel-example-etl; type=osgi.bundle;
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused
> by: Unable to resolve camel-example-etl/2.20.0.SNAPSHOT: missing requirement
> [camel-example-etl/2.20.0.SNAPSHOT] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.apache.openjpa.enhance)(version>=2.4.0)(!(version>=3.0.0)))"
> [caused by: Unable to resolve org.apache.openjpa/2.4.2: missing requirement
> [org.apache.openjpa/2.4.2] osgi.wiring.package;
> filter:="(osgi.wiring.package=org.apache.commons.dbcp)"]]]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE
Robert Half created CAMEL-11846: --- Summary: xtokenize and apply xslt to a string does not work with UTF-16BE Key: CAMEL-11846 URL: https://issues.apache.org/jira/browse/CAMEL-11846 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.17.5 Reporter: Robert Half In XML, encoding is often provided inside tag. In general, you cannot read the tag, if you don't know the encoding, but XML Parsers support the detection of several encodings which allows them to read the tag. With that information they can read the whole file without knowing the "charset" in first place. xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by providing a reader Camel tells, that it knows the encoding, so it won't be detected by the XML parser. Also Camel sets the charset to UTF-8 if it is not provided inside a header. This makes the underlying reader fail reading UTF-16. Using XmlInputFactory#createXmlStreamReader(InputStream) inside XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps fails again because it again uses a Reader. See Stackoverflow Question for reference: [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180874#comment-16180874
]
ASF GitHub Bot commented on CAMEL-11842:
GitHub user jamesnetherton opened a pull request:
https://github.com/apache/camel/pull/1963
CAMEL-11842: CNFE when configuring camel-docker TLS options
https://issues.apache.org/jira/browse/CAMEL-11842
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jamesnetherton/camel CAMEL-11842
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1963.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 #1963
commit 89e2ba937934bfd10eb1064f3efd393d14c888d0
Author: James Netherton
Date: 2017-09-26T13:47:44Z
CAMEL-11842: CNFE when configuring camel-docker TLS options
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>Assignee: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11845) Migrate easymock and powermock to mockito
Claus Ibsen created CAMEL-11845: --- Summary: Migrate easymock and powermock to mockito Key: CAMEL-11845 URL: https://issues.apache.org/jira/browse/CAMEL-11845 Project: Camel Issue Type: Test Reporter: Claus Ibsen Fix For: Future We want to only use one kind of mock testing library. They are a pain to maintain and too much fuzz/magic going on. The majority is using mockito, and its more popular. Contributions is welcome to migrate the components that uses easymock or powermock -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180810#comment-16180810 ] Önder Sezgin commented on CAMEL-7621: - Should be fine now. > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180807#comment-16180807 ] ASF GitHub Bot commented on CAMEL-7621: --- Github user onders86 closed the pull request at: https://github.com/apache/camel/pull/1954 > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11808) log4j2 2.9 upgrade causes errors in camel-salesforce and others
[ https://issues.apache.org/jira/browse/CAMEL-11808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180808#comment-16180808 ] ASF GitHub Bot commented on CAMEL-11808: Github user vrlgohel closed the pull request at: https://github.com/apache/camel/pull/1962 > log4j2 2.9 upgrade causes errors in camel-salesforce and others > --- > > Key: CAMEL-11808 > URL: https://issues.apache.org/jira/browse/CAMEL-11808 > Project: Camel > Issue Type: Task > Components: build system >Affects Versions: 2.21.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.21.0 > > > [12:28:26] davsclaus, master build fails with [ERROR] > Failed to execute goal > org.apache.maven.plugins:maven-plugin-plugin:3.4:helpmojo (help-goal) on > project camel-salesforce-maven-plugin: Execution help-goal of goal > org.apache.maven.plugins:maven-plugin-plugin:3.4:helpmojo failed. > IllegalArgumentException -> [Help 1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (CAMEL-11809) Manage org.immutables:value in the BoM
[
https://issues.apache.org/jira/browse/CAMEL-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga closed CAMEL-11809.
Resolution: Not A Problem
[~davsclaus] yeah, I can confirm that `org.immutables:value` is not needed at
runtime. Thus there is no point in managing it. Thanks again for suggesting to
check if it is required at runtime.
> Manage org.immutables:value in the BoM
> --
>
> Key: CAMEL-11809
> URL: https://issues.apache.org/jira/browse/CAMEL-11809
> Project: Camel
> Issue Type: Task
>Reporter: Peter Palaga
>Assignee: Peter Palaga
>
> {{org.immutables:value}} is required by {{consul-client}} but is declared as
> {{provided}} because of what its version is not passed transitively. It thus
> needs to be managed in the BoM.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11809) Manage org.immutables:value in the BoM
[
https://issues.apache.org/jira/browse/CAMEL-11809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180797#comment-16180797
]
ASF GitHub Bot commented on CAMEL-11809:
Github user ppalaga closed the pull request at:
https://github.com/apache/camel/pull/1951
> Manage org.immutables:value in the BoM
> --
>
> Key: CAMEL-11809
> URL: https://issues.apache.org/jira/browse/CAMEL-11809
> Project: Camel
> Issue Type: Task
>Reporter: Peter Palaga
>Assignee: Peter Palaga
>
> {{org.immutables:value}} is required by {{consul-client}} but is declared as
> {{provided}} because of what its version is not passed transitively. It thus
> needs to be managed in the BoM.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11844) camel-azure - Should work with Camel file component OOTB
[ https://issues.apache.org/jira/browse/CAMEL-11844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-11844. - Resolution: Fixed > camel-azure - Should work with Camel file component OOTB > > > Key: CAMEL-11844 > URL: https://issues.apache.org/jira/browse/CAMEL-11844 > Project: Camel > Issue Type: Bug > Components: camel-azure >Affects Versions: 2.19.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.19.4, 2.20.0 > > > See SO > https://stackoverflow.com/questions/46425049/camel-azure-blobserviceproducer-illegalargumentexception-unsupported-blob-type -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11844) camel-azure - Should work with Camel file component OOTB
Claus Ibsen created CAMEL-11844: --- Summary: camel-azure - Should work with Camel file component OOTB Key: CAMEL-11844 URL: https://issues.apache.org/jira/browse/CAMEL-11844 Project: Camel Issue Type: Bug Components: camel-azure Affects Versions: 2.19.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.19.4, 2.20.0 See SO https://stackoverflow.com/questions/46425049/camel-azure-blobserviceproducer-illegalargumentexception-unsupported-blob-type -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180781#comment-16180781 ] ASF GitHub Bot commented on CAMEL-7621: --- GitHub user onders86 reopened a pull request: https://github.com/apache/camel/pull/1954 CAMEL-7621 - new(named as method)data field annotation added as des… …cribed in the issue as the following https://issues.apache.org/jira/browse/CAMEL-7621?focusedCommentId=16023475&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16023475 You can merge this pull request into a Git repository by running: $ git pull https://github.com/onders86/camel CAMEL-7621 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1954.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 #1954 commit fbbef4bf725860f856d1ed2c0c252fbb7a2e947a Author: onders86 Date: 2017-09-24T16:40:21Z CAMEL-7621 - new(named as function)data field annotation added as described in the issue as the following https://issues.apache.org/jira/browse/CAMEL-7621?focusedCommentId=16023475&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16023475 Renaming package name > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11843) Unable to configure some URI options on DockerEndpoint
James Netherton created CAMEL-11843:
---
Summary: Unable to configure some URI options on DockerEndpoint
Key: CAMEL-11843
URL: https://issues.apache.org/jira/browse/CAMEL-11843
Project: Camel
Issue Type: Improvement
Components: camel-docker
Affects Versions: 2.19.3, 2.20.0
Reporter: James Netherton
Priority: Minor
The docker component triggers some [custom
logic|https://github.com/apache/camel/blob/master/components/camel-docker/src/main/java/org/apache/camel/component/docker/DockerComponent.java#L65]
to validate URI options.
It does not handle all of the valid set of URI options. E.g setting
exchangePattern, maxTotalConnections and others, results in:
{code}
Caused by: com.github.dockerjava.api.exception.DockerClientException:
bridgeErrorHandler is not a valid URI parameter
at
org.apache.camel.component.docker.DockerHelper.validateParameters(DockerHelper.java:56)
at
org.apache.camel.component.docker.DockerComponent.createEndpoint(DockerComponent.java:65)
at
org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:126)
at
org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:703)
... 51 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11824.
-
Resolution: Fixed
Assignee: Claus Ibsen
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180750#comment-16180750
]
Claus Ibsen commented on CAMEL-11824:
-
Okay have a fix so the unit test cleanup for itself so when you start the app
its running on 9080 as expected.
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180746#comment-16180746
]
Claus Ibsen commented on CAMEL-11824:
-
The problem is that it runs a test first before starting and thus create
target/custom.properties that override the default ports.
We need to make it not test when you run the example with mvn camel:run
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180743#comment-16180743
]
Önder Sezgin commented on CAMEL-11824:
--
https://github.com/apache/camel/blob/master/examples/camel-example-cxf-proxy/src/test/java/org/apache/camel/example/reportincident/ReportIncidentRoutesTest.java#L44
Yes agree with Tomo. 1101 and 1102 come from
https://github.com/apache/camel/blob/3505e718db48cc0d8be5b47f6c4030c958d93a5f/components/camel-test/src/main/java/org/apache/camel/test/AvailablePortFinder.java#L37
It is not choice. :)
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180742#comment-16180742
]
Tomohisa Igarashi commented on CAMEL-11824:
---
And if it's finding free port and possibly another port number would be used,
then it also should be described in README, i.e. which log shows the correct
port number to connect.
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Netherton reassigned CAMEL-11842:
---
Assignee: James Netherton
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>Assignee: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180736#comment-16180736
]
Tomohisa Igarashi edited comment on CAMEL-11824 at 9/26/17 1:07 PM:
README should be aligned if 1101/1102 is likely to be used. incident.properties
also should be removed as it's confusing. IMHO 1101/1102 look odd, 9080/9081
look better for testing port.
was (Author: igarashitm):
If it's expected then incident.properties also should be removed as it's
confusing. IMHO 1101/1102 look odd, 9080/9081 look better for testing port.
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180736#comment-16180736
]
Tomohisa Igarashi commented on CAMEL-11824:
---
If it's expected then incident.properties also should be removed as it's
confusing. IMHO 1101/1102 look odd, 9080/9081 look better for testing port.
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180735#comment-16180735
]
Claus Ibsen commented on CAMEL-11842:
-
Yeah that sounds like a plan, you are welcome to provide a PR
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180727#comment-16180727
]
James Netherton commented on CAMEL-11842:
-
I raised: https://github.com/docker-java/docker-java/issues/922
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[
https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart resolved CAMEL-11814.
---
Resolution: Fixed
I've merged from [PR#1961|https://github.com/apache/camel/pull/1961] into
{{master}}, this way the ThreadLocal NO_START flag is preserved, and the issue
with CamelMainRunController trying to start CamelContext in parallel was
diverted by having the CamelMainRunController thread start after CamelContext
is started (from a StartupListener).
> camel-spring-boot - Recent change in startup behaviour can cause
> camel-test-spring problems
> ---
>
> Key: CAMEL-11814
> URL: https://issues.apache.org/jira/browse/CAMEL-11814
> Project: Camel
> Issue Type: Bug
> Components: camel-spring, camel-spring-boot
>Affects Versions: 2.20.0
>Reporter: Claus Ibsen
>Assignee: Zoran Regvart
> Fix For: 2.20.0
>
>
> Creating this ticket up front as I was testing CiA2 source code with
> 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the
> test method to be executed without CamelContext been started prior - this
> works fine on 2.19.x and older versions.
> Its very likely the new startup/shutdown change in camel-spring /
> camel-spring-boot that is causing a regression problem. A bit weird our own
> set of unit tests at Apache Camel hasn't triggered this.
> Doing some more testing on CiA2 before posting more information here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180704#comment-16180704
]
chandra shekhar pandey commented on CAMEL-11824:
It is as per junit test case, which set any available free port. Range starts
from 1101, it is also logged as below.
2017-09-26 17:50:08,756 [main ] INFO AvailablePortFinder
- getNextAvailable(1101) -> 1101
2017-09-26 17:50:08,759 [main ] INFO AvailablePortFinder
- getNextAvailable(1102) -> 1102
It is expected scenario, let me know if still it is required to modify ReadMe
file.
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11482.
-
Resolution: Fixed
Thanks those SSL tests are extreme and they are hard to test as different
platforms and JDKs and whatnot have different ciphers supported etc.
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[ https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180702#comment-16180702 ] ASF GitHub Bot commented on CAMEL-11814: Github user zregvart closed the pull request at: https://github.com/apache/camel/pull/1961 > camel-spring-boot - Recent change in startup behaviour can cause > camel-test-spring problems > --- > > Key: CAMEL-11814 > URL: https://issues.apache.org/jira/browse/CAMEL-11814 > Project: Camel > Issue Type: Bug > Components: camel-spring, camel-spring-boot >Affects Versions: 2.20.0 >Reporter: Claus Ibsen >Assignee: Zoran Regvart > Fix For: 2.20.0 > > > Creating this ticket up front as I was testing CiA2 source code with > 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the > test method to be executed without CamelContext been started prior - this > works fine on 2.19.x and older versions. > Its very likely the new startup/shutdown change in camel-spring / > camel-spring-boot that is causing a regression problem. A bit weird our own > set of unit tests at Apache Camel hasn't triggered this. > Doing some more testing on CiA2 before posting more information here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180699#comment-16180699 ] Önder Sezgin commented on CAMEL-7621: - will have a look. spring context xmls seem got lost while squashing.. will fix it soon. > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180697#comment-16180697
]
James Netherton commented on CAMEL-11842:
-
As a short-term fix for standalone camel / Spring Boot, maybe we remove the
Jersey exclusions from the camel-docker POM.
The camel-docker OSGi feature should continue still work OK for non SSL usage
and we could perhaps fix the SSL functionality in a future release.
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
[
https://issues.apache.org/jira/browse/CAMEL-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180694#comment-16180694
]
Claus Ibsen commented on CAMEL-11842:
-
Can you try to report this to the docker-java library
> ClassNotFoundException when configuring camel-docker SSL options
>
>
> Key: CAMEL-11842
> URL: https://issues.apache.org/jira/browse/CAMEL-11842
> Project: Camel
> Issue Type: Bug
> Components: camel-docker
>Affects Versions: 2.20.0
>Reporter: James Netherton
>
> We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
> CmdExecFactory. As part of this work the transitive Jersey libraries from the
> docker-java library were excluded.
> Unfortunately, it seems docker-java still depends on Jersey stuff, even when
> configured to use Netty. If I try to configure SSL options, I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError:
> org/glassfish/jersey/SslConfigurator
> at
> com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
> at
> com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
> at
> com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
> at
> com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
> at
> com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
> at
> com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException:
> org.glassfish.jersey.SslConfigurator
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 62 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11842) ClassNotFoundException when configuring camel-docker SSL options
James Netherton created CAMEL-11842:
---
Summary: ClassNotFoundException when configuring camel-docker SSL
options
Key: CAMEL-11842
URL: https://issues.apache.org/jira/browse/CAMEL-11842
Project: Camel
Issue Type: Bug
Components: camel-docker
Affects Versions: 2.20.0
Reporter: James Netherton
We had the idea in CAMEL-11256 to switch to using Netty as the docker-java
CmdExecFactory. As part of this work the transitive Jersey libraries from the
docker-java library were excluded.
Unfortunately, it seems docker-java still depends on Jersey stuff, even when
configured to use Netty. If I try to configure SSL options, I get:
{code}
Caused by: java.lang.NoClassDefFoundError: org/glassfish/jersey/SslConfigurator
at
com.github.dockerjava.core.LocalDirectorySSLConfig.getSSLContext(LocalDirectorySSLConfig.java:56)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.initSsl(NettyDockerCmdExecFactory.java:340)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory$InetSocketInitializer.connect(NettyDockerCmdExecFactory.java:322)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:220)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory.connect(NettyDockerCmdExecFactory.java:213)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory.access$000(NettyDockerCmdExecFactory.java:157)
at
com.github.dockerjava.netty.NettyDockerCmdExecFactory$1.getChannel(NettyDockerCmdExecFactory.java:183)
at
com.github.dockerjava.netty.InvocationBuilder.getChannel(InvocationBuilder.java:213)
at
com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:196)
at
com.github.dockerjava.netty.InvocationBuilder.get(InvocationBuilder.java:187)
at
com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:41)
at
com.github.dockerjava.netty.exec.ListImagesCmdExec.execute(ListImagesCmdExec.java:16)
at
com.github.dockerjava.netty.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
at
com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
at
org.apache.camel.component.docker.producer.DockerProducer.process(DockerProducer.java:115)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
... 46 more
Caused by: java.lang.ClassNotFoundException:
org.glassfish.jersey.SslConfigurator
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 62 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180690#comment-16180690 ] Claus Ibsen commented on CAMEL-7621: Onder, do you get unit test failure on camel-bindy as well, there is a single test that fails now BindySimpleFixedLengthUnmarshallClassMethodTest > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180661#comment-16180661
]
Roman Vottner commented on CAMEL-11482:
---
Test for exclusion pattern. Both tests are green though you might notice a
stacktrace on executing testHelloEndpoint as no server certificate is
obtainable:
https://github.com/RovoMe/camel/blob/fix/CAMEL-11482_SSLContextParameters_settings_are_not_properly_copied_to_SslContextFactory/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/HttpsRouteSslContextParametersInUriTest_TLSv1SupportWithExclusionPattern.java
Test for defining explicite ciphers to support. Though as it turns out Jettys
exclusion patterns seem to kick in before and hence remove all of the TLSv1/1.1
ciphers:
https://github.com/RovoMe/camel/blob/fix/CAMEL-11482_SSLContextParameters_settings_are_not_properly_copied_to_SslContextFactory/components/camel-jetty9/src/test/java/org/apache/camel/component/jetty/HttpsRouteSslContextParametersInUriTest_TLSv1SupportWithInclusionPattern.java
HTH
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>
[jira] [Resolved] (CAMEL-11841) cluster service : make a simple FileLock based service
[ https://issues.apache.org/jira/browse/CAMEL-11841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luca Burgazzoli resolved CAMEL-11841. - Resolution: Fixed > cluster service : make a simple FileLock based service > -- > > Key: CAMEL-11841 > URL: https://issues.apache.org/jira/browse/CAMEL-11841 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Labels: clustering > Fix For: 2.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11824) [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
[
https://issues.apache.org/jira/browse/CAMEL-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180647#comment-16180647
]
Önder Sezgin commented on CAMEL-11824:
--
not sure where 1102 and 1101 comes from;
https://github.com/apache/camel/blob/master/examples/camel-example-cxf-proxy/src/main/resources/incident.properties#L19
> [example] cxf-proxy, loan-broker-cxf - port 1101/1102 is unexpectedly used
> --
>
> Key: CAMEL-11824
> URL: https://issues.apache.org/jira/browse/CAMEL-11824
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> target/classes/incident.properties is not effective, not sure which one of
> that and target/custom.properties should be. If it's using expected port then
> update README
> {code}
> INFO: Setting the server's publish address to be
> http://localhost:1102/real-webservice
> INFO: Setting the server's publish address to be
> http://localhost:1101/camel-example-cxf-proxy/webservices/incident
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180624#comment-16180624
]
Claus Ibsen commented on CAMEL-11482:
-
Yeah you are welcome to contribute your unit tests that would help surely.
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180616#comment-16180616
]
Roman Vottner commented on CAMEL-11482:
---
Thanks for taking over as I'm currently not having enough time lately. I've
some (WIP) tests for the changes I had in my branch if you are interested. They
basically test that TLSv1 or TLSv1.1 connections work as they should via Java's
HttpUrlConnection. The only thing that bugs me, is, that I am not able to
retrieve the server certificate but I'm not sure if this is related to
self-signed certificates.
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(serv
[jira] [Commented] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180610#comment-16180610
]
Claus Ibsen commented on CAMEL-11482:
-
I am working on this, and we now set those ciphers and protocols filters from
the ssl context configuration.
Camel will log at INFO level the configuration, such as the default ones as
shown
{code}
Connector on por:t 23003 is using excludeChiperSuites: [[^.*_(MD5|SHA|SHA1)$]]
excludeProtocols: [[SSL, SSLv2, SSLv2Hello, SSLv3]]
{code}
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
> }
> {code}
--
This message was sent by
[jira] [Commented] (CAMEL-11247) camel-spring-boot - Improve BOM to work better with start.spring.io
[ https://issues.apache.org/jira/browse/CAMEL-11247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180609#comment-16180609 ] Nicola Ferraro commented on CAMEL-11247: I've moved the BOM generation into the "/bom" dir where we now generate a "camel-bom" artifact. This contains only "org.apache.camel" artifacts and can be used for any purpose, including spring-boot start.spring.io. > camel-spring-boot - Improve BOM to work better with start.spring.io > --- > > Key: CAMEL-11247 > URL: https://issues.apache.org/jira/browse/CAMEL-11247 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot, camel-spring-boot-starters >Reporter: Claus Ibsen >Assignee: Nicola Ferraro > Fix For: 2.20.0 > > > See this PR > https://github.com/spring-io/initializr/pull/425#issuecomment-299801788 > I tried locally to set the initializer to use our current BOM for spring-boot > starters, but the project it generates causes the mvn to not build. > We should IMHO try to get this working so we can use a BOM in the > start.spring.io wizard so people get a nicer project build out of the box. > Which is also what the Spring guys is asking for. > You can try the initializer locally, by following instructions at > https://github.com/spring-io/initializr#running-the-app-locally > Then you can thinker in the yml file to setup a Camel BOM > https://github.com/spring-io/initializr/blob/master/initializr-service/src/main/resources/application.yml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11808) log4j2 2.9 upgrade causes errors in camel-salesforce and others
[ https://issues.apache.org/jira/browse/CAMEL-11808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180590#comment-16180590 ] ASF GitHub Bot commented on CAMEL-11808: GitHub user vrlgohel opened a pull request: https://github.com/apache/camel/pull/1962 CAMEL-11808: log4j2 2.9 upgrade causes errors in camel build Fix for issue: https://issues.apache.org/jira/browse/CAMEL-11808 The 'maven-plugin-plugin' was failing. There's a little bit of tweaking involved here as I am not sure how log4j 2.9 transitively affects this plugin, but, there were some existing issues with this plugin as the below, which we haven't made changes in camel, https://issues.apache.org/jira/browse/MPLUGIN-238 http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html The 'HelpMojo' goal was affected. I am not sure if the version 3.4 of the plugin contains the fix, because it does not work! Upgrading the version after making the suggested changes has no issues with the build. camel-servicenow and camel-salesforce maven plugins failed in the build and now the build is working fine along-with the iTests. You can merge this pull request into a Git repository by running: $ git pull https://github.com/vrlgohel/camel-1 CAMEL-11808 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1962.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 #1962 commit b0545ce35357385942c0bb72d6e58d80cc58081b Author: Viral Gohel Date: 2017-09-26T10:15:38Z CAMEL-11808: log4j2 2.9 upgrade causes errors in camel build > log4j2 2.9 upgrade causes errors in camel-salesforce and others > --- > > Key: CAMEL-11808 > URL: https://issues.apache.org/jira/browse/CAMEL-11808 > Project: Camel > Issue Type: Task > Components: build system >Affects Versions: 2.21.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.21.0 > > > [12:28:26] davsclaus, master build fails with [ERROR] > Failed to execute goal > org.apache.maven.plugins:maven-plugin-plugin:3.4:helpmojo (help-goal) on > project camel-salesforce-maven-plugin: Execution help-goal of goal > org.apache.maven.plugins:maven-plugin-plugin:3.4:helpmojo failed. > IllegalArgumentException -> [Help 1] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[ https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180571#comment-16180571 ] ASF GitHub Bot commented on CAMEL-11814: GitHub user zregvart opened a pull request: https://github.com/apache/camel/pull/1961 CAMEL-11814: makes NO_START a ThreadLocal, and ... ...changes the way CamelMainRunController is started We need to change NO_START flag back to ThreadLocal as there is a use case when it's used from a single classloader outside of the tests in wildfly-camel. CamelMainRunController would atempt to start CamelContext from a thread that does not have the NO_START flag defined (it's a ThreadLocal), so it can only run when CamelContext is started. It's main purpose is to prevent the SpringBoot application JVM from terminating so having it run when the CamelContext is started doesn't prevent that. You can merge this pull request into a Git repository by running: $ git pull https://github.com/zregvart/camel CAMEL-11814 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/1961.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 #1961 commit b53773853e8fff5cad3854ed096812b844086080 Author: Zoran Regvart Date: 2017-09-26T10:03:12Z CAMEL-11814: makes NO_START a ThreadLocal, and ... ...changes the way CamelMainRunController is started We need to change NO_START flag back to ThreadLocal as there is a use case when it's used from a single classloader outside of the tests in wildfly-camel. CamelMainRunController would atempt to start CamelContext from a thread that does not have the NO_START flag defined (it's a ThreadLocal), so it can only run when CamelContext is started. It's main purpose is to prevent the SpringBoot application JVM from terminating so having it run when the CamelContext is started doesn't prevent that. > camel-spring-boot - Recent change in startup behaviour can cause > camel-test-spring problems > --- > > Key: CAMEL-11814 > URL: https://issues.apache.org/jira/browse/CAMEL-11814 > Project: Camel > Issue Type: Bug > Components: camel-spring, camel-spring-boot >Affects Versions: 2.20.0 >Reporter: Claus Ibsen >Assignee: Zoran Regvart > Fix For: 2.20.0 > > > Creating this ticket up front as I was testing CiA2 source code with > 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the > test method to be executed without CamelContext been started prior - this > works fine on 2.19.x and older versions. > Its very likely the new startup/shutdown change in camel-spring / > camel-spring-boot that is causing a regression problem. A bit weird our own > set of unit tests at Apache Camel hasn't triggered this. > Doing some more testing on CiA2 before posting more information here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11841) cluster service : make a simple FileLock based service
[ https://issues.apache.org/jira/browse/CAMEL-11841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-11841 started by Luca Burgazzoli. --- > cluster service : make a simple FileLock based service > -- > > Key: CAMEL-11841 > URL: https://issues.apache.org/jira/browse/CAMEL-11841 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Labels: clustering > Fix For: 2.20.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11482) SSLContextParameters settings are not properly copied to SslContextFactory
[
https://issues.apache.org/jira/browse/CAMEL-11482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-11482:
---
Assignee: Claus Ibsen
> SSLContextParameters settings are not properly copied to SslContextFactory
> --
>
> Key: CAMEL-11482
> URL: https://issues.apache.org/jira/browse/CAMEL-11482
> Project: Camel
> Issue Type: Bug
> Components: camel-jetty
>Affects Versions: 2.19.0, 2.19.1
> Environment: Max OS X, Java 8 Update 131
> Ubuntu 14.04 LTS, Java 8 Update 111
> Camel 2.19.0
> Jetty9 9.4.5v20170502 and 9.3.14.v20161028
>Reporter: Roman Vottner
>Assignee: Claus Ibsen
> Fix For: 2.19.4, 2.20.0
>
>
> Jetty 9.3+ excludes unsecure ciphers which end on either MD5, SHA or SHA1 by
> default now. This will however remove all ciphers that are used by either
> TLSv1 or TLSv1.1 and thus no ciphers remain in order to agree on a cipher for
> TLSv1 or TLSv1.1 connection attempts. (Further reading:
> https://github.com/eclipse/jetty.project/issues/860)
> The Jetty 9 SSL configuration documentation
> (https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html)
> states that this exclusion cipher suites can be customized by providing an
> own exclusion list. On specifying SSLContextParameters like below however
> will not correctly propagate this exclution cipher suites to the
> SslContextFactory of Jetty and thus use the default setting which prevents
> TLSv1 and TLSv1.1 connections.
> {code:title=SSLContextParameters Spring Config|borderStyle=solid}
> @Bean(name = "sslContextParameters")
> public SSLContextParameters sslContextParameters() {
> String keyStore = env.getProperty("ssl.keyStore.resource");
> URL keyStoreUrl = this.getClass().getResource(keyStore);
> // http://camel.apache.org/jetty.html
> KeyStoreParameters ksp = new KeyStoreParameters();
> ksp.setResource(keyStoreUrl.getPath());
> ksp.setPassword(env.getProperty("ssl.keyStore.password"));
> KeyManagersParameters kmp = new KeyManagersParameters();
> kmp.setKeyStore(ksp);
> kmp.setKeyPassword(env.getProperty("ssl.key.password"));
> SSLContextParameters scp = new SSLContextParameters();
> scp.setKeyManagers(kmp);
> // Jetty 9.3+ support only TLSv1.2 by default hence clients not
> supporting this protocol will fail
> List supportedSslProtocols = Arrays.asList("TLSv1", "TLSv1.1",
> "TLSv1.2");
> SecureSocketProtocolsParameters protocolsParameters = new
> SecureSocketProtocolsParameters();
> protocolsParameters.setSecureSocketProtocol(supportedSslProtocols);
> scp.setSecureSocketProtocols(protocolsParameters);
> // TLS 1.0 / 1.1 have been disabled by jetty 9.3
> // this is a first attempt to re-enable them
> // see
> // -
> https://www.eclipse.org/jetty/documentation/9.3.x/configuring-ssl.html
> // - https://github.com/eclipse/jetty.project/issues/860
> // - http://camel.apache.org/camel-configuration-utilities.html
> FilterParameters cipherParameters = new FilterParameters();
> cipherParameters.getInclude().add(".*");
> cipherParameters.getExclude().add("^.*_(MD5|SHA1)$");
> scp.setCipherSuitesFilter(cipherParameters);
> return scp;
> }
> {code}
> A workaround is to use a custom JettyHttpComponent9 implementation that sets
> the excludedCipherSuites manually like depicted below:
> {code:title=Workaround|borderStyle=solid}
> /**
>* A custom jetty http component which explicitly sets the
> excludedCipherSuites during creation of
>* the jetty connector.
>*
>* Why? It seems camel does not push included/excluded cipherSuites from
> {@link
>* SSLContextParameters} to the {@link SslContextFactory} nor does push
> explicitly listed cipher
>* suites (i.e. like TLS_RSA_WITH_AES_256_CBC_SHA) to the Jetty
> SSL context factory.
>*/
> public static class HackedJettyHttpComponent extends JettyHttpComponent9 {
> @Override
> protected AbstractConnector createConnectorJettyInternal(Server server,
>
> JettyHttpEndpoint endpoint,
>
> SslContextFactory sslcf) {
> sslcf.setExcludeCipherSuites("^.*_(MD5|SHA1)$");
> return super.createConnectorJettyInternal(server, endpoint, sslcf);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-9008) Contributing GRPC / Thrift support to Camel
[ https://issues.apache.org/jira/browse/CAMEL-9008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180522#comment-16180522 ] Claus Ibsen commented on CAMEL-9008: If you can find the time this week / evening that would be great, as otherwise chances are this is going to slip the release. > Contributing GRPC / Thrift support to Camel > --- > > Key: CAMEL-9008 > URL: https://issues.apache.org/jira/browse/CAMEL-9008 > Project: Camel > Issue Type: New Feature >Reporter: Andrew Harmel-Law >Assignee: Dmitry Volodin > Fix For: 2.20.0 > > > Hi, > We're building Microservices with Camel, predominantly producing from REST > DSL components and have got to the point where having an easy way to swap in > GRPC [1] / Thrift [2] endpoints and clients would be of great help. > We wondered if this was already on the cards for a future release, and if we > might be able to work on it, and if not, if it would be something we could > work on and contribute (with guidance to smooth the design and > implementation)? > Kind regards, the Capgemini UK and Indian Camel teams > [1] http://www.grpc.io/ > [2] https://thrift.apache.org/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11827) [example] spring-boot-servicecall - service1 returns 404 not found
[
https://issues.apache.org/jira/browse/CAMEL-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180499#comment-16180499
]
ASF GitHub Bot commented on CAMEL-11827:
Github user ramu11 closed the pull request at:
https://github.com/apache/camel/pull/1956
> [example] spring-boot-servicecall - service1 returns 404 not found
> --
>
> Key: CAMEL-11827
> URL: https://issues.apache.org/jira/browse/CAMEL-11827
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> {code}
> $ curl localhost:8080/camel/serviceCall/service1
> org.apache.camel.http.common.HttpOperationFailedException: HTTP operation
> failed invoking http://localhost:9011/ with statusCode: 404
> at
> org.apache.camel.component.undertow.UndertowClientCallback.lambda$setupResponseListener$2(UndertowClientCallback.java:232)
> at
> org.apache.camel.component.undertow.UndertowClientCallback$ErrorHandlingClientCallback.completed(UndertowClientCallback.java:86)
> at
> io.undertow.client.http.HttpClientExchange.setResponse(HttpClientExchange.java:125)
> at
> io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:647)
> at
> io.undertow.client.http.HttpClientConnection$ClientReadListener.handleEvent(HttpClientConnection.java:516)
> at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at
> org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:561)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[
https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart reopened CAMEL-11814:
---
Assignee: Zoran Regvart (was: Claus Ibsen)
I've discussed this change with the {{wildfly-camel}} team, a single
classloader is used for SpringCamelContext, we need to use {{ThreadLocal}} and
we need to control {{CamelMainRunController}} based on that.
> camel-spring-boot - Recent change in startup behaviour can cause
> camel-test-spring problems
> ---
>
> Key: CAMEL-11814
> URL: https://issues.apache.org/jira/browse/CAMEL-11814
> Project: Camel
> Issue Type: Bug
> Components: camel-spring, camel-spring-boot
>Affects Versions: 2.20.0
>Reporter: Claus Ibsen
>Assignee: Zoran Regvart
> Fix For: 2.20.0
>
>
> Creating this ticket up front as I was testing CiA2 source code with
> 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the
> test method to be executed without CamelContext been started prior - this
> works fine on 2.19.x and older versions.
> Its very likely the new startup/shutdown change in camel-spring /
> camel-spring-boot that is causing a regression problem. A bit weird our own
> set of unit tests at Apache Camel hasn't triggered this.
> Doing some more testing on CiA2 before posting more information here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11826) [example] hystrix, opentracing - spring-boot:run throws NPE
[
https://issues.apache.org/jira/browse/CAMEL-11826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-11826.
-
Resolution: Fixed
Assignee: Claus Ibsen
hystrix also works
> [example] hystrix, opentracing - spring-boot:run throws NPE
> ---
>
> Key: CAMEL-11826
> URL: https://issues.apache.org/jira/browse/CAMEL-11826
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> {code}
> 2017-09-22 20:16:29.684 ERROR 19603 --- [ main]
> o.s.boot.SpringApplication : Application startup failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'cacheAutoConfigurationValidatorPostProcessor'
> defined in class path resource
> [org/apache/camel/component/http/springboot/HttpComponentSSLAutoConfiguration.class]:
> Unsatisfied dependency expressed through method
> 'cacheAutoConfigurationValidatorPostProcessor' parameter 0; nested exception
> is org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'camelContext' defined in class path resource
> [org/apache/camel/spring/boot/CamelAutoConfiguration.class]: Bean
> instantiation via factory method failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.apache.camel.CamelContext]: Factory method 'camelContext' threw
> exception; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'routesHealthCheckRepository' defined in class path resource
> [org/apache/camel/spring/boot/health/HealthCheckRoutesAutoConfiguration.class]:
> Bean instantiation via factory method failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.apache.camel.health.HealthCheckRepository]: Factory method
> 'routesHealthCheckRepository' threw exception; nested exception is
> java.lang.NullPointerException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:749)
> ~[spring-beans-4.3.11.RELEASE.jar:4.3.11.RELEASE]
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:467)
> ~[spring-beans-4.3.11.RELEASE.jar:4.3.11.RELEASE]
> .
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.camel.spring.boot.health.HealthCheckRoutesAutoConfiguration.routesHealthCheckRepository(HealthCheckRoutesAutoConfiguration.java:50)
> ~[camel-spring-boot-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT]
> at
> org.apache.camel.spring.boot.health.HealthCheckRoutesAutoConfiguration$$EnhancerBySpringCGLIB$$aa43f327.CGLIB$routesHealthCheckRepository$0()
> ~[camel-spring-boot-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT]
> .
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11826) [example] hystrix, opentracing - spring-boot:run throws NPE
[
https://issues.apache.org/jira/browse/CAMEL-11826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180480#comment-16180480
]
Claus Ibsen commented on CAMEL-11826:
-
The opentracing example works now
> [example] hystrix, opentracing - spring-boot:run throws NPE
> ---
>
> Key: CAMEL-11826
> URL: https://issues.apache.org/jira/browse/CAMEL-11826
> Project: Camel
> Issue Type: Sub-task
> Components: examples
>Reporter: Tomohisa Igarashi
> Fix For: 2.20.0
>
>
> {code}
> 2017-09-22 20:16:29.684 ERROR 19603 --- [ main]
> o.s.boot.SpringApplication : Application startup failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'cacheAutoConfigurationValidatorPostProcessor'
> defined in class path resource
> [org/apache/camel/component/http/springboot/HttpComponentSSLAutoConfiguration.class]:
> Unsatisfied dependency expressed through method
> 'cacheAutoConfigurationValidatorPostProcessor' parameter 0; nested exception
> is org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'camelContext' defined in class path resource
> [org/apache/camel/spring/boot/CamelAutoConfiguration.class]: Bean
> instantiation via factory method failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.apache.camel.CamelContext]: Factory method 'camelContext' threw
> exception; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'routesHealthCheckRepository' defined in class path resource
> [org/apache/camel/spring/boot/health/HealthCheckRoutesAutoConfiguration.class]:
> Bean instantiation via factory method failed; nested exception is
> org.springframework.beans.BeanInstantiationException: Failed to instantiate
> [org.apache.camel.health.HealthCheckRepository]: Factory method
> 'routesHealthCheckRepository' threw exception; nested exception is
> java.lang.NullPointerException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:749)
> ~[spring-beans-4.3.11.RELEASE.jar:4.3.11.RELEASE]
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:467)
> ~[spring-beans-4.3.11.RELEASE.jar:4.3.11.RELEASE]
> .
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.camel.spring.boot.health.HealthCheckRoutesAutoConfiguration.routesHealthCheckRepository(HealthCheckRoutesAutoConfiguration.java:50)
> ~[camel-spring-boot-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT]
> at
> org.apache.camel.spring.boot.health.HealthCheckRoutesAutoConfiguration$$EnhancerBySpringCGLIB$$aa43f327.CGLIB$routesHealthCheckRepository$0()
> ~[camel-spring-boot-2.20.0-SNAPSHOT.jar:2.20.0-SNAPSHOT]
> .
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[
https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180472#comment-16180472
]
Zoran Regvart edited comment on CAMEL-11814 at 9/26/17 8:42 AM:
I've changed the {{NO_START}} flag to be a global (static) {{AtomicBoolean}}
this will help with race conditions between {{CamelMainRunController}} and
{{SpringCamelContext/CamelContextFactoryBean}} on different threads.
This fix conditions itself upon different {{(Spring)CamelContexts}} being in
different classloaders to work. As far as I'm aware this is true for
{{wildfly-camel}}; and integration tests support makes sure to manage the flag
in single thread.
was (Author: zregvart):
I've changed the {{NO_START}} flag to be a global (static) {{AtomicBoolean}}
this will help with race conditions between {{CamelMainRunController}} and
{{SpringCamelContext/CamelContextFactoryBean}} on different threads.
This fix conditions itself upon different {{(Spring}CamelContexts}} being in
different classloaders to work.
> camel-spring-boot - Recent change in startup behaviour can cause
> camel-test-spring problems
> ---
>
> Key: CAMEL-11814
> URL: https://issues.apache.org/jira/browse/CAMEL-11814
> Project: Camel
> Issue Type: Bug
> Components: camel-spring, camel-spring-boot
>Affects Versions: 2.20.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Creating this ticket up front as I was testing CiA2 source code with
> 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the
> test method to be executed without CamelContext been started prior - this
> works fine on 2.19.x and older versions.
> Its very likely the new startup/shutdown change in camel-spring /
> camel-spring-boot that is causing a regression problem. A bit weird our own
> set of unit tests at Apache Camel hasn't triggered this.
> Doing some more testing on CiA2 before posting more information here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11814) camel-spring-boot - Recent change in startup behaviour can cause camel-test-spring problems
[
https://issues.apache.org/jira/browse/CAMEL-11814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoran Regvart resolved CAMEL-11814.
---
Resolution: Fixed
I've changed the {{NO_START}} flag to be a global (static) {{AtomicBoolean}}
this will help with race conditions between {{CamelMainRunController}} and
{{SpringCamelContext/CamelContextFactoryBean}} on different threads.
This fix conditions itself upon different {{(Spring}CamelContexts}} being in
different classloaders to work.
> camel-spring-boot - Recent change in startup behaviour can cause
> camel-test-spring problems
> ---
>
> Key: CAMEL-11814
> URL: https://issues.apache.org/jira/browse/CAMEL-11814
> Project: Camel
> Issue Type: Bug
> Components: camel-spring, camel-spring-boot
>Affects Versions: 2.20.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 2.20.0
>
>
> Creating this ticket up front as I was testing CiA2 source code with
> 2.20.0-SNAPSHOT and have issues with a camel spring boot app, that caused the
> test method to be executed without CamelContext been started prior - this
> works fine on 2.19.x and older versions.
> Its very likely the new startup/shutdown change in camel-spring /
> camel-spring-boot that is causing a regression problem. A bit weird our own
> set of unit tests at Apache Camel hasn't triggered this.
> Doing some more testing on CiA2 before posting more information here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-10806) Create camel-rxjava2 component
[ https://issues.apache.org/jira/browse/CAMEL-10806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-10806: Fix Version/s: (was: 2.20.0) 2.21.0 > Create camel-rxjava2 component > -- > > Key: CAMEL-10806 > URL: https://issues.apache.org/jira/browse/CAMEL-10806 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Luca Burgazzoli >Priority: Minor > Fix For: 2.21.0 > > > A we have now camel-reactive-streams it would be nice to have a RxJava 2 > implementation of the camel-reactive-streams API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11449) start.spring.io - Define version range
[ https://issues.apache.org/jira/browse/CAMEL-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-11449. - Resolution: Fixed > start.spring.io - Define version range > -- > > Key: CAMEL-11449 > URL: https://issues.apache.org/jira/browse/CAMEL-11449 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.20.0 > > > We should setup a version range for Camel in start.spring.io website. > Camel 2.20.x supports Spring Boot 1.5.x > Camel 2.19.x supports Spring Boot 1.5.x > Camel 2.18.x supports Spring Boot 1.4.x and 1.5.x -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11835) cluster service : make a JGroups based cluster service
[ https://issues.apache.org/jira/browse/CAMEL-11835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180440#comment-16180440 ] Andrea Tarocchi commented on CAMEL-11835: - [~lb], I'd like to work on it, not sure I can make it for the 2.20. I'll do my best ;) > cluster service : make a JGroups based cluster service > -- > > Key: CAMEL-11835 > URL: https://issues.apache.org/jira/browse/CAMEL-11835 > Project: Camel > Issue Type: Improvement > Components: camel-jgroups >Reporter: Luca Burgazzoli > Labels: clustering > Fix For: 2.20.0 > > > It would be nice to have a jgroups based cluster service implementation with > the following two variants: > 1. using View were the leader is the older member (aka coordinator) > 2. using distributed locks > [~valdar] I know you were interested to implement this, do you think we can > make it for 2.20 ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Önder Sezgin resolved CAMEL-7621. - Resolution: Implemented Fix Version/s: 2.20.0 > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Fix For: 2.20.0 > > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-7621) camel-bindy - Two new properties to StringFormat through DataField: toUppercase and mapToASCII
[ https://issues.apache.org/jira/browse/CAMEL-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180384#comment-16180384 ] ASF GitHub Bot commented on CAMEL-7621: --- Github user onders86 closed the pull request at: https://github.com/apache/camel/pull/1954 > camel-bindy - Two new properties to StringFormat through DataField: > toUppercase and mapToASCII > -- > > Key: CAMEL-7621 > URL: https://issues.apache.org/jira/browse/CAMEL-7621 > Project: Camel > Issue Type: New Feature > Components: camel-bindy >Reporter: Bruno Fontana >Assignee: Önder Sezgin >Priority: Minor > Attachments: > Adding-properties-to-mapToASCII-and-to-convert-to-Up.patch > > > We faced many times the need of converting string fields to uppercase and get > rid of non-ASCII characters when interacting, using fixed-length files, with > COBOL banking cores. > So we decided to patch our own version of camel-bindy to add two new > properties to DataField annotation: > toUpperCase= which converts, if its a String type field, content > to uppercase. > mapToASCII= which maps, if its a String type field, content to > 7-bit ASCII character mapping. Extended characters are currently mapped like > this > ä,â,á,à -> a (same for all vowels) > ß -> b > ç -> c > ñ -> n > Conversion uses a lookup table so it could be easily extended to other chars. > This conversion only applies when marshalling. This feature has proven very > useful to us when interacting with banking cores and one that repeatedly has > to be recoded or reused. We love the annotation-driven model of bindy so > decided to patch our own version and submit the patch hoping it would be as > useful to others as it is to us. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11840) camel-itest-karaf - CamelLinkedinTest fails
[
https://issues.apache.org/jira/browse/CAMEL-11840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180354#comment-16180354
]
ASF GitHub Bot commented on CAMEL-11840:
Github user tadayosi closed the pull request at:
https://github.com/apache/camel/pull/1960
> camel-itest-karaf - CamelLinkedinTest fails
> ---
>
> Key: CAMEL-11840
> URL: https://issues.apache.org/jira/browse/CAMEL-11840
> Project: Camel
> Issue Type: Test
> Components: karaf, tests
>Affects Versions: 2.20.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 2.20.0
>
>
> {code}
> $ ./run-tests.sh CamelLinkedinTest
> ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.382 sec
> <<< FAILURE! - in org.apache.camel.itest.karaf.CamelLinkedinTest
> test(org.apache.camel.itest.karaf.CamelLinkedinTest) Time elapsed: 10.262
> sec <<< ERROR!
> org.ops4j.pax.exam.WrappedTestContainerException:
> [test(org.apache.camel.itest.karaf.CamelLinkedinTest): Unable to resolve
> root: missing requirement [root] osgi.identity; osgi.identity=camel-linkedin;
> type=karaf.feature; version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]";
> filter:="(&(osgi.identity=camel-linkedin)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
> [caused by: Unable to resolve camel-linkedin/2.20.0.SNAPSHOT: missing
> requirement [camel-linkedin/2.20.0.SNAPSHOT] osgi.identity;
> osgi.identity=org.apache.camel.camel-linkedin; type=osgi.bundle;
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused
> by: Unable to resolve org.apache.camel.camel-linkedin/2.20.0.SNAPSHOT:
> missing requirement [org.apache.camel.camel-linkedin/2.20.0.SNAPSHOT]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.apache.camel.component.linkedin.api.model)(version>=2.20.0)(!(version>=2.21.0)))"
> [caused by: Unable to resolve
> org.apache.camel.camel-linkedin-api/2.20.0.SNAPSHOT: missing requirement
> [org.apache.camel.camel-linkedin-api/2.20.0.SNAPSHOT] osgi.wiring.package;
> filter:="(osgi.wiring.package=com.gargoylesoftware.htmlunit.util)" [caused
> by: Unable to resolve org.apache.servicemix.bundles.htmlunit/2.24.0.1:
> missing requirement [org.apache.servicemix.bundles.htmlunit/2.24.0.1]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.client)(version>=9.2.0)(!(version>=10.0.0)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.client/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.client/9.3.14.v20161028] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.api.extensions)(version>=9.3.14)(!(version>=9.3.15)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.api/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.api/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-jetty-condition-pax_http_whiteboard; type=karaf.feature;
> version="[9.3.14.v20161028,9.3.14.v20161028]"; resolution:=mandatory [caused
> by: Unable to resolve
> pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028: missing requirement
> [pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-http-whiteboard; type=karaf.feature; condition:=true
> at
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Tests in error:
> CamelLinkedinTest.test » WrappedTestContainer
> [test(org.apache.camel.itest.kar...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> ---
[jira] [Commented] (CAMEL-11839) camel-itest-karaf - CamelBoxTest fails
[
https://issues.apache.org/jira/browse/CAMEL-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180352#comment-16180352
]
Tadayoshi Sato commented on CAMEL-11839:
I see.
> camel-itest-karaf - CamelBoxTest fails
> --
>
> Key: CAMEL-11839
> URL: https://issues.apache.org/jira/browse/CAMEL-11839
> Project: Camel
> Issue Type: Test
> Components: camel-box, karaf, tests
>Affects Versions: 2.20.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 2.20.0
>
>
> {code}
> $ ./run-tests.sh CamelBoxTest
> ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.242 sec
> <<< FAILURE! - in org.apache.camel.itest.karaf.CamelBoxTest
> test(org.apache.camel.itest.karaf.CamelBoxTest) Time elapsed: 10.097 sec
> <<< ERROR!
> org.ops4j.pax.exam.WrappedTestContainerException:
> [test(org.apache.camel.itest.karaf.CamelBoxTest): Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=camel-box;
> type=karaf.feature; version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]";
> filter:="(&(osgi.identity=camel-box)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
> [caused by: Unable to resolve camel-box/2.20.0.SNAPSHOT: missing requirement
> [camel-box/2.20.0.SNAPSHOT] osgi.identity;
> osgi.identity=org.apache.camel.camel-box; type=osgi.bundle;
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused
> by: Unable to resolve org.apache.camel.camel-box/2.20.0.SNAPSHOT: missing
> requirement [org.apache.camel.camel-box/2.20.0.SNAPSHOT] osgi.wiring.package;
> filter:="(osgi.wiring.package=com.gargoylesoftware.htmlunit.util)" [caused
> by: Unable to resolve org.apache.servicemix.bundles.htmlunit/2.24.0.1:
> missing requirement [org.apache.servicemix.bundles.htmlunit/2.24.0.1]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.client)(version>=9.2.0)(!(version>=10.0.0)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.client/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.client/9.3.14.v20161028] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.api.extensions)(version>=9.3.14)(!(version>=9.3.15)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.api/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.api/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-jetty-condition-pax_http_whiteboard; type=karaf.feature;
> version="[9.3.14.v20161028,9.3.14.v20161028]"; resolution:=mandatory [caused
> by: Unable to resolve
> pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028: missing requirement
> [pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-http-whiteboard; type=karaf.feature; condition:=true]]]
> at
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Tests in error:
> CamelBoxTest.test » WrappedTestContainer
> [test(org.apache.camel.itest.karaf.Ca...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.446 s
> [INFO] Finished at: 2017-09-26T09:48:27+09:00
> [INFO] Final Memory: 41M/2875M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11839) camel-itest-karaf - CamelBoxTest fails
[
https://issues.apache.org/jira/browse/CAMEL-11839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180353#comment-16180353
]
ASF GitHub Bot commented on CAMEL-11839:
Github user tadayosi closed the pull request at:
https://github.com/apache/camel/pull/1959
> camel-itest-karaf - CamelBoxTest fails
> --
>
> Key: CAMEL-11839
> URL: https://issues.apache.org/jira/browse/CAMEL-11839
> Project: Camel
> Issue Type: Test
> Components: camel-box, karaf, tests
>Affects Versions: 2.20.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 2.20.0
>
>
> {code}
> $ ./run-tests.sh CamelBoxTest
> ...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.242 sec
> <<< FAILURE! - in org.apache.camel.itest.karaf.CamelBoxTest
> test(org.apache.camel.itest.karaf.CamelBoxTest) Time elapsed: 10.097 sec
> <<< ERROR!
> org.ops4j.pax.exam.WrappedTestContainerException:
> [test(org.apache.camel.itest.karaf.CamelBoxTest): Unable to resolve root:
> missing requirement [root] osgi.identity; osgi.identity=camel-box;
> type=karaf.feature; version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]";
> filter:="(&(osgi.identity=camel-box)(type=karaf.feature)(version>=2.20.0.SNAPSHOT)(version<=2.20.0.SNAPSHOT))"
> [caused by: Unable to resolve camel-box/2.20.0.SNAPSHOT: missing requirement
> [camel-box/2.20.0.SNAPSHOT] osgi.identity;
> osgi.identity=org.apache.camel.camel-box; type=osgi.bundle;
> version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]"; resolution:=mandatory [caused
> by: Unable to resolve org.apache.camel.camel-box/2.20.0.SNAPSHOT: missing
> requirement [org.apache.camel.camel-box/2.20.0.SNAPSHOT] osgi.wiring.package;
> filter:="(osgi.wiring.package=com.gargoylesoftware.htmlunit.util)" [caused
> by: Unable to resolve org.apache.servicemix.bundles.htmlunit/2.24.0.1:
> missing requirement [org.apache.servicemix.bundles.htmlunit/2.24.0.1]
> osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.client)(version>=9.2.0)(!(version>=10.0.0)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.client/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.client/9.3.14.v20161028] osgi.wiring.package;
> filter:="(&(osgi.wiring.package=org.eclipse.jetty.websocket.api.extensions)(version>=9.3.14)(!(version>=9.3.15)))"
> [caused by: Unable to resolve
> org.eclipse.jetty.websocket.api/9.3.14.v20161028: missing requirement
> [org.eclipse.jetty.websocket.api/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-jetty-condition-pax_http_whiteboard; type=karaf.feature;
> version="[9.3.14.v20161028,9.3.14.v20161028]"; resolution:=mandatory [caused
> by: Unable to resolve
> pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028: missing requirement
> [pax-jetty-condition-pax_http_whiteboard/9.3.14.v20161028] osgi.identity;
> osgi.identity=pax-http-whiteboard; type=karaf.feature; condition:=true]]]
> at
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
> at
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:389)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:347)
> at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:218)
> at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:291)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1233)
> at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$0(FeaturesServiceImpl.java:1132)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Results :
> Tests in error:
> CamelBoxTest.test » WrappedTestContainer
> [test(org.apache.camel.itest.karaf.Ca...
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.446 s
> [INFO] Finished at: 2017-09-26T09:48:27+09:00
> [INFO] Final Memory: 41M/2875M
> [INFO]
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
