[jira] [Closed] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[
https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato closed CAMEL-20598.
--
Resolution: Fixed
Fixed with Hawtio 4.0.0-RC2:
{code}
camel hawtio --version=4.0.0-RC2
{code}
> camel-jbang - Cannot use hawtio v4
> --
>
> Key: CAMEL-20598
> URL: https://issues.apache.org/jira/browse/CAMEL-20598
> Project: Camel
> Issue Type: Task
> Components: camel-jbang
>Reporter: Claus Ibsen
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 4.5.0
>
>
> When using
> camel run foo.java
> camel hawtio foo
> then it works with 3.0.x
> but if you want to try with 4.0.x
> camel hawtio foo --version=4.0.0-RC1
> you get a classloading issue
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-20598: --- Fix Version/s: 4.5.0 (was: 4.6.0) > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: 4.5.0 > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work started] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-20598 started by Tadayoshi Sato. -- > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: 4.x > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830201#comment-17830201 ] Tadayoshi Sato commented on CAMEL-20598: It should be fixed once Hawtio 4.0.0 GA is released. https://github.com/hawtio/hawtio/pull/3325 > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: 4.x > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-20598) camel-jbang - Cannot use hawtio v4
[ https://issues.apache.org/jira/browse/CAMEL-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato reassigned CAMEL-20598: -- Assignee: Tadayoshi Sato > camel-jbang - Cannot use hawtio v4 > -- > > Key: CAMEL-20598 > URL: https://issues.apache.org/jira/browse/CAMEL-20598 > Project: Camel > Issue Type: Task > Components: camel-jbang >Reporter: Claus Ibsen >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: 4.x > > > When using > camel run foo.java > camel hawtio foo > then it works with 3.0.x > but if you want to try with 4.0.x > camel hawtio foo --version=4.0.0-RC1 > you get a classloading issue -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19813) camel-yaml-dsl - Error handler should be oneOf
[ https://issues.apache.org/jira/browse/CAMEL-19813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761266#comment-17761266 ] Tadayoshi Sato commented on CAMEL-19813: Maybe you meant [~igarashitm]? > camel-yaml-dsl - Error handler should be oneOf > -- > > Key: CAMEL-19813 > URL: https://issues.apache.org/jira/browse/CAMEL-19813 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.1.0 > > > In this class > org.apache.camel.dsl.yaml.deserializers.RouteConfigurationDefinitionDeserializer > Then there is an option for "error-handler" which refers to the 5+ error > handlers we have in Camel. > In the schema then it looks like its an array where you can use 0..n of them. > But the realitiy is that you can choose to use only one of them. So either > you use default error handler, or you use dead letter channel, and not both > of them. > The new oneOf in the @YamlProperty may be useful if we can make it generate > correct yaml schema output. Or we need to adjust the generator source to make > this work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18823) Provide option to download dependencies to a specific folder with Camel JBang/camel CLI
[
https://issues.apache.org/jira/browse/CAMEL-18823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17649164#comment-17649164
]
Tadayoshi Sato commented on CAMEL-18823:
[~apupier] By the way, there is a new {{camel dependencies}} command in Camel
3.20.0 release, which has similar features:
{code}
$ camel dependencies -h
Usage: camel dependencies [-h] [--fresh] [--gradle-wrapper] [--logging]
[--maven-wrapper] [--quiet]
[--build-tool=]
[--camel-spring-boot-version=]
[--dep=] [-dir=]
[--gav=] [--java-version=]
[--kamelets-version=]
[--local-kamelet-dir=]
[--logging-level=]
[--main-classname=]
[--output=] [--profile=]
[--quarkus-artifact-id=]
[--quarkus-group-id=]
[--quarkus-version=]
[--runtime=]
[--spring-boot-version=]
Displays all Camel dependencies required to run
--build-tool=
Build tool to use (maven or gradle)
--camel-spring-boot-version=
Camel version to use with Spring Boot
--dep, --deps=
Add additional dependencies (Use commas to separate
multiple dependencies).
-dir, --directory=
Directory where the project will be exported
--fresh Make sure we use fresh (i.e. non-cached) resources
--gav= The Maven group:artifact:version
--gradle-wrapper Include Gradle Wrapper files in exported project
-h, --helpDisplay the help and sub-commands
--java-version=
Java version (11 or 17)
--kamelets-version=
Apache Camel Kamelets version
--local-kamelet-dir=
Local directory for loading Kamelets (takes
precedence)
--logging Can be used to turn on logging (logs to file in
/.camel directory)
--logging-level=
Logging level
--main-classname=
The class name of the Camel Main application class
--maven-wrapper Include Maven Wrapper files in exported project
--output= Output format (gav or maven)
--profile= Profile to use, which refers to loading properties
file with the given profile name. By default
application.properties is loaded.
--quarkus-artifact-id=
Quarkus Platform Maven artifactId
--quarkus-group-id=
Quarkus Platform Maven groupId
--quarkus-version=
Quarkus Platform version
--quiet Will be quiet, only print when error occurs
--runtime= Runtime (spring-boot, quarkus, or camel-main)
--spring-boot-version=
Spring Boot version
{code}
> Provide option to download dependencies to a specific folder with Camel
> JBang/camel CLI
> ---
>
> Key: CAMEL-18823
> URL: https://issues.apache.org/jira/browse/CAMEL-18823
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Reporter: Aurélien Pupier
>Priority: Major
>
> Camel K 1.11 is deprecating _kamel local_ with the idea to move features in
> camel cli
> A functionality used by VS Code Camel K was to download dependencies in a
> specific folder using something like: _kamel local build
> --integration-directory "" MyRoute.java_
> Currently camel cli allows to gather list of depednencies but not to download
> them
> [https://camel.apache.org/manual/camel-jbang.html#_gathering_list_of_dependencies]
> it would be convenient to have an option to download the dependencies in a
> specific folder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18497) camel-jbang - camel run -v x.y.z
[
https://issues.apache.org/jira/browse/CAMEL-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638518#comment-17638518
]
Tadayoshi Sato commented on CAMEL-18497:
[~davsclaus] Yes, it's true about downgrading, and since {{camel-jbang-core}}
is also parameterised with {{camel.jbang.version}} it's not so much different
from using {{-Dcamel.jbang.version=3.18.3}}:
{code}
//DEPS org.apache.camel:camel-jbang-core:${camel.jbang.version:3.19.0}
{code}
So truly achieving parameterisation of Camel version with Camel JBang,
{{camel-jbang-core}} and {{camel-jbang-main}} need to be combined and installed
via JBang on the fly. I agree that this task is a bigger one.
> camel-jbang - camel run -v x.y.z
>
>
> Key: CAMEL-18497
> URL: https://issues.apache.org/jira/browse/CAMEL-18497
> Project: Camel
> Issue Type: Task
> Components: camel-jbang
>Reporter: Pasquale Congiusti
>Priority: Minor
> Fix For: 3.x
>
>
> We can specify any Camel version when using the jbang CLI as documented in:
> https://camel.apache.org/manual/camel-jbang.html#_using_a_specific_camel_version
> However, it would be nice to have the same feature when using directly camel
> CLI, in order to have the very same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18497) camel-jbang - camel run -v x.y.z
[
https://issues.apache.org/jira/browse/CAMEL-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17638496#comment-17638496
]
Tadayoshi Sato commented on CAMEL-18497:
[~squakez] [~davsclaus] Actually, JBang already allows specifying a branch or
tag when installing an app:
{code}
jbang app install @(/repository)(/branch)(~path)
{code}
https://www.jbang.dev/documentation/guide/latest/alias_catalogs.html#implicit-alias-catalogs
so you can already do:
{code}
jbang app install camel@apache/camel/camel-3.18.3
{code}
to use a specific version of Camel.
The problem is, though, in Camel side, where the {{CamelJBang}} at the
{{camel-3.18.3}} still points to {{3.18.2}}.
https://github.com/apache/camel/blob/camel-3.18.3/dsl/camel-jbang/camel-jbang-main/dist/CamelJBang.java
To make this version switch really available, the Camel release process would
need to first update the {{CamelJBang}} and then do a release.
FYI [~acosentino]
> camel-jbang - camel run -v x.y.z
>
>
> Key: CAMEL-18497
> URL: https://issues.apache.org/jira/browse/CAMEL-18497
> Project: Camel
> Issue Type: Task
> Components: camel-jbang
>Reporter: Pasquale Congiusti
>Priority: Minor
> Fix For: 3.x
>
>
> We can specify any Camel version when using the jbang CLI as documented in:
> https://camel.apache.org/manual/camel-jbang.html#_using_a_specific_camel_version
> However, it would be nice to have the same feature when using directly camel
> CLI, in order to have the very same behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18719) camel-jbang - Adding the dependency of camel-quarkus-core creates two entries in exported POM.xml
[
https://issues.apache.org/jira/browse/CAMEL-18719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-18719:
---
Component/s: camel-jbang
> camel-jbang - Adding the dependency of camel-quarkus-core creates two entries
> in exported POM.xml
> -
>
> Key: CAMEL-18719
> URL: https://issues.apache.org/jira/browse/CAMEL-18719
> Project: Camel
> Issue Type: Bug
> Components: camel-jbang
>Affects Versions: 3.20.0
>Reporter: Mrinal
>Priority: Major
>
> {code:java}
> jbang --debug --verbose -Dcamel.jbang.version=3.20.0-SNAPSHOT
> ../CamelJBang.java export
> --deps=org.apache.camel.quarkus:camel-quarkus-core:2.13.0 {code}
> The above command created an exported project with pom.xml with two
> camel-quarkus dependency.
> {code:java}
>
>
> org.apache.camel.quarkus
> camel-quarkus-core
>
>
> org.apache.camel.quarkus
> camel-quarkus-platform-http
>
>
> org.apache.camel.quarkus
> camel-quarkus-microprofile-health
>
>
> org.apache.camel.quarkus
> camel-quarkus-core
> 2.13.0
>
>
> org.apache.camel.quarkus
> camel-quarkus-direct
>
>
> org.apache.camel.quarkus
> camel-quarkus-rest
>
>
> org.apache.camel.quarkus
> camel-quarkus-yaml-dsl
>
>
>
> null
>
>
> io.quarkus
> quarkus-junit5
> test
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18721) camel-jbang - name/pid completion for camel top/stop commands
[
https://issues.apache.org/jira/browse/CAMEL-18721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-18721:
---
Description:
Similarly to CAMEL-18716, we can provide positional parameter completion for
integration names and pids with {{camel top}} and {{{}camel stop{}}}:
{code:java}
$ camel top context [TAB]
$ camel stop [TAB]
{code}
But implementing this should be a bit trickier as the completion script needs
to call back {{camel ps}} to get completion candidates. We can embed the
completion by using Picocli's {{@Parameters}} {{completionCandidates}}
attribute.
was:
Similarly to CAMEL-18716, we can provide positional parameter completion for
names and pids with {{camel top}} and {{camel stop}}:
{code}
$ camel top context [TAB]
$ camel stop [TAB]
{code}
But implementing this should be a bit trickier as the completion script needs
to call back {{camel ps}} to get completion candidates. We can embed the
completion by using Picocli's {{@Parameters}} {{completionCandidates}}
attribute.
> camel-jbang - name/pid completion for camel top/stop commands
> -
>
> Key: CAMEL-18721
> URL: https://issues.apache.org/jira/browse/CAMEL-18721
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Similarly to CAMEL-18716, we can provide positional parameter completion for
> integration names and pids with {{camel top}} and {{{}camel stop{}}}:
> {code:java}
> $ camel top context [TAB]
> $ camel stop [TAB]
> {code}
> But implementing this should be a bit trickier as the completion script needs
> to call back {{camel ps}} to get completion candidates. We can embed the
> completion by using Picocli's {{@Parameters}} {{completionCandidates}}
> attribute.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-18721) camel-jbang - name/pid completion for camel top/stop commands
[
https://issues.apache.org/jira/browse/CAMEL-18721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato reassigned CAMEL-18721:
--
Assignee: Tadayoshi Sato
> camel-jbang - name/pid completion for camel top/stop commands
> -
>
> Key: CAMEL-18721
> URL: https://issues.apache.org/jira/browse/CAMEL-18721
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Similarly to CAMEL-18716, we can provide positional parameter completion for
> names and pids with {{camel top}} and {{camel stop}}:
> {code}
> $ camel top context [TAB]
> $ camel stop [TAB]
> {code}
> But implementing this should be a bit trickier as the completion script needs
> to call back {{camel ps}} to get completion candidates. We can embed the
> completion by using Picocli's {{@Parameters}} {{completionCandidates}}
> attribute.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18721) camel-jbang - name/pid completion for camel top/stop commands
Tadayoshi Sato created CAMEL-18721:
--
Summary: camel-jbang - name/pid completion for camel top/stop
commands
Key: CAMEL-18721
URL: https://issues.apache.org/jira/browse/CAMEL-18721
Project: Camel
Issue Type: New Feature
Components: camel-jbang
Affects Versions: 3.19.0
Reporter: Tadayoshi Sato
Similarly to CAMEL-18716, we can provide positional parameter completion for
names and pids with {{camel top}} and {{camel stop}}:
{code}
$ camel top context [TAB]
$ camel stop [TAB]
{code}
But implementing this should be a bit trickier as the completion script needs
to call back {{camel ps}} to get completion candidates. We can embed the
completion by using Picocli's {{@Parameters}} {{completionCandidates}}
attribute.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18720) camel-jbang - camel top [name] selection not working as expected
[
https://issues.apache.org/jira/browse/CAMEL-18720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-18720:
---
Description:
There seems to be a minor problem with selection of integrations based on their
names with {{camel top}} commands. For example:
{code}
$ camel run a.java
$ camel run aa.java
$ camel run aaa.java
{code}
Then:
{code}
$ camel top context
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 5m58s 0/0/0 267/656/8319
MB 62/66 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 5m52s 0/0/0 262/641/8319
MB 62/66 MB 38ms (5) 8/9
130555 a 11.0.17 3.19.0 Camel Running 6m2s 0/0/0 130/645/8319
MB 62/66 MB 50ms (7) 8/9
{code}
But:
{code}
$ camel top context a
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m32s 0/0/0 95/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m28s 0/0/0 95/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m22s 0/0/0 90/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m35s 0/0/0 97/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m31s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m25s 0/0/0 92/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aaa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 1m34s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m28s 0/0/0 94/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context
PIDNAME JAVA CAMEL PLATFORM STATUS AGE LOADHEAP
NON-HEAP GC THREADS
131963 aaa 11.0.17 3.19.0 Camel Running 2m6s 0/0/0 120/641/8319 MB
60/64 MB 38ms (5) 8/9
$ camel top context a
{code}
PID based selection works fine.
was:
There seems to be a minor problem with selection of integrations based on their
names with {{camel top}} commands. For example:
{code}
$ camel run a.java
$ camel run aa.java
$ camel run aaa.java
{code}
Then:
{code}
camel top context
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 5m58s 0/0/0 267/656/8319
MB 62/66 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 5m52s 0/0/0 262/641/8319
MB 62/66 MB 38ms (5) 8/9
130555 a 11.0.17 3.19.0 Camel Running 6m2s 0/0/0 130/645/8319
MB 62/66 MB 50ms (7) 8/9
{code}
But:
{code}
$ camel top context a
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m32s 0/0/0 95/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m28s 0/0/0 95/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m22s 0/0/0 90/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m35s 0/0/0 97/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m31s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m25s 0/0/0 92/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aaa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 1m34s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m28s 0/0/0 94/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context
PIDNAME JAVA CAMEL PLATFORM STATUS AGE LOADHEAP
NON-HEAP GC THREADS
131963 aaa 11.0.17 3.19.0 Camel Running 2m6s 0/0/0 120/641/8319 MB
60/64 MB 38ms (5) 8/9
$ camel top context a
{code}
PID based selection works fine.
> camel-jbang - camel top [name] selection not working as expected
>
>
>
[jira] [Created] (CAMEL-18720) camel-jbang - camel top [name] selection not working as expected
Tadayoshi Sato created CAMEL-18720:
--
Summary: camel-jbang - camel top [name] selection not working as
expected
Key: CAMEL-18720
URL: https://issues.apache.org/jira/browse/CAMEL-18720
Project: Camel
Issue Type: Bug
Components: camel-jbang
Affects Versions: 3.19.0
Reporter: Tadayoshi Sato
There seems to be a minor problem with selection of integrations based on their
names with {{camel top}} commands. For example:
{code}
$ camel run a.java
$ camel run aa.java
$ camel run aaa.java
{code}
Then:
{code}
camel top context
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 5m58s 0/0/0 267/656/8319
MB 62/66 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 5m52s 0/0/0 262/641/8319
MB 62/66 MB 38ms (5) 8/9
130555 a 11.0.17 3.19.0 Camel Running 6m2s 0/0/0 130/645/8319
MB 62/66 MB 50ms (7) 8/9
{code}
But:
{code}
$ camel top context a
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m32s 0/0/0 95/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m28s 0/0/0 95/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m22s 0/0/0 90/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
130555 a 11.0.17 3.19.0 Camel Running 1m35s 0/0/0 97/645/8319 MB
60/64 MB 42ms (6) 8/9
131260 aa11.0.17 3.19.0 Camel Running 1m31s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m25s 0/0/0 92/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context aaa
PIDNAME JAVA CAMEL PLATFORM STATUSAGE LOADHEAP
NON-HEAP GC THREADS
131260 aa11.0.17 3.19.0 Camel Running 1m34s 0/0/0 97/656/8319 MB
60/63 MB 51ms (5) 8/9
131963 aaa 11.0.17 3.19.0 Camel Running 1m28s 0/0/0 94/641/8319 MB
60/63 MB 38ms (5) 8/9
$ camel top context
PIDNAME JAVA CAMEL PLATFORM STATUS AGE LOADHEAP
NON-HEAP GC THREADS
131963 aaa 11.0.17 3.19.0 Camel Running 2m6s 0/0/0 120/641/8319 MB
60/64 MB 38ms (5) 8/9
$ camel top context a
{code}
PID based selection works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18716) camel-jbang - Provide completion for positional file path parameters
[
https://issues.apache.org/jira/browse/CAMEL-18716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-18716.
Fix Version/s: 3.20.0
Resolution: Fixed
> camel-jbang - Provide completion for positional file path parameters
>
>
> Key: CAMEL-18716
> URL: https://issues.apache.org/jira/browse/CAMEL-18716
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.20.0
>
>
> Shell completion is provided with CAMEL-18673, but file path completion for
> positional parameters such as:
> {code}
> $ camel run [TAB]
> $ camel pipe [TAB]
> {code}
> doesn't work, because it seems Picocli disables the default fallback Bash
> completion.
> -To support such file path completion, it seems we need an enhancement to
> Picocli:-
> https://github.com/remkop/picocli/issues/1871
> Discussing with the author of Picocli I found a way to implement it within
> Camel JBang.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (CAMEL-18716) camel-jbang - Provide completion for positional file path parameters
[
https://issues.apache.org/jira/browse/CAMEL-18716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-18716 started by Tadayoshi Sato.
--
> camel-jbang - Provide completion for positional file path parameters
>
>
> Key: CAMEL-18716
> URL: https://issues.apache.org/jira/browse/CAMEL-18716
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Shell completion is provided with CAMEL-18673, but file path completion for
> positional parameters such as:
> {code}
> $ camel run [TAB]
> $ camel pipe [TAB]
> {code}
> doesn't work, because it seems Picocli disables the default fallback Bash
> completion.
> -To support such file path completion, it seems we need an enhancement to
> Picocli:-
> https://github.com/remkop/picocli/issues/1871
> Discussing with the author of Picocli I found a way to implement it within
> Camel JBang.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18716) camel-jbang - Provide completion for positional file path parameters
[
https://issues.apache.org/jira/browse/CAMEL-18716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-18716:
---
Description:
Shell completion is provided with CAMEL-18673, but file path completion for
positional parameters such as:
{code}
$ camel run [TAB]
$ camel pipe [TAB]
{code}
doesn't work, because it seems Picocli disables the default fallback Bash
completion.
-To support such file path completion, it seems we need an enhancement to
Picocli:-
https://github.com/remkop/picocli/issues/1871
Discussing with the author of Picocli I found a way to implement it within
Camel JBang.
was:
Shell completion is provided with CAMEL-18673, but file path completion for
positional parameters such as:
{code}
$ camel run [TAB]
$ camel pipe [TAB]
{code}
doesn't work, because it seems Picocli disables the default fallback Bash
completion.
To support such file path completion, it seems we need an enhancement to
Picocli:
https://github.com/remkop/picocli/issues/1871
> camel-jbang - Provide completion for positional file path parameters
>
>
> Key: CAMEL-18716
> URL: https://issues.apache.org/jira/browse/CAMEL-18716
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Shell completion is provided with CAMEL-18673, but file path completion for
> positional parameters such as:
> {code}
> $ camel run [TAB]
> $ camel pipe [TAB]
> {code}
> doesn't work, because it seems Picocli disables the default fallback Bash
> completion.
> -To support such file path completion, it seems we need an enhancement to
> Picocli:-
> https://github.com/remkop/picocli/issues/1871
> Discussing with the author of Picocli I found a way to implement it within
> Camel JBang.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18716) camel-jbang - Provide completion for positional file path parameters
Tadayoshi Sato created CAMEL-18716:
--
Summary: camel-jbang - Provide completion for positional file path
parameters
Key: CAMEL-18716
URL: https://issues.apache.org/jira/browse/CAMEL-18716
Project: Camel
Issue Type: New Feature
Components: camel-jbang
Affects Versions: 3.19.0
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
Shell completion is provided with CAMEL-18673, but file path completion for
positional parameters such as:
{code}
$ camel run [TAB]
$ camel pipe [TAB]
{code}
doesn't work, because it seems Picocli disables the default fallback Bash
completion.
To support such file path completion, it seems we need an enhancement to
Picocli:
https://github.com/remkop/picocli/issues/1871
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18673) camel-jbang - Provide shell completions for camel CLI
[
https://issues.apache.org/jira/browse/CAMEL-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-18673.
Resolution: Fixed
> camel-jbang - Provide shell completions for camel CLI
> -
>
> Key: CAMEL-18673
> URL: https://issues.apache.org/jira/browse/CAMEL-18673
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.20.0
>
>
> camel-jbang is a great tool to interact with Camel applications. It would be
> even greater if it provides a command that generates completion scripts for
> the popular shells such as bash, zsh, etc.
> {code}
> $ camel completion [bash|zsh|...]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Work started] (CAMEL-18673) camel-jbang - Provide shell completions for camel CLI
[
https://issues.apache.org/jira/browse/CAMEL-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-18673 started by Tadayoshi Sato.
--
> camel-jbang - Provide shell completions for camel CLI
> -
>
> Key: CAMEL-18673
> URL: https://issues.apache.org/jira/browse/CAMEL-18673
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.20.0
>
>
> camel-jbang is a great tool to interact with Camel applications. It would be
> even greater if it provides a command that generates completion scripts for
> the popular shells such as bash, zsh, etc.
> {code}
> $ camel completion [bash|zsh|...]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18673) camel-jbang - Provide shell completions for camel CLI
[
https://issues.apache.org/jira/browse/CAMEL-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632033#comment-17632033
]
Tadayoshi Sato commented on CAMEL-18673:
If no one else is yet to work on it, I will.
> camel-jbang - Provide shell completions for camel CLI
> -
>
> Key: CAMEL-18673
> URL: https://issues.apache.org/jira/browse/CAMEL-18673
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Priority: Major
>
> camel-jbang is a great tool to interact with Camel applications. It would be
> even greater if it provides a command that generates completion scripts for
> the popular shells such as bash, zsh, etc.
> {code}
> $ camel completion [bash|zsh|...]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-18673) camel-jbang - Provide shell completions for camel CLI
[
https://issues.apache.org/jira/browse/CAMEL-18673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato reassigned CAMEL-18673:
--
Assignee: Tadayoshi Sato
> camel-jbang - Provide shell completions for camel CLI
> -
>
> Key: CAMEL-18673
> URL: https://issues.apache.org/jira/browse/CAMEL-18673
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
>Affects Versions: 3.19.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> camel-jbang is a great tool to interact with Camel applications. It would be
> even greater if it provides a command that generates completion scripts for
> the popular shells such as bash, zsh, etc.
> {code}
> $ camel completion [bash|zsh|...]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18698) Add support for multiple data types on components
[
https://issues.apache.org/jira/browse/CAMEL-18698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631026#comment-17631026
]
Tadayoshi Sato edited comment on CAMEL-18698 at 11/9/22 12:01 PM:
--
There are related tickets already about data types on components.
CAMEL-10447
CAMEL-11132
CAMEL-17620
was (Author: tadayosi):
There are related tickets already about data types on components.
CAMEL-11132
CAMEL-17620
> Add support for multiple data types on components
> -
>
> Key: CAMEL-18698
> URL: https://issues.apache.org/jira/browse/CAMEL-18698
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Christoph Deppisch
>Priority: Major
>
> Each component consumes/produces input and output data when processing the
> exchange as part of the route. Usually a component reads data from the
> exchange message (body and header) as input and produces specific message
> content as an output.
> The input and output of a component can be of various nature (e.g. Java POJO
> objects, Json objects, String, binary data, InputStream, etc.)
> In order to simplify the interrelationship between components each component
> should allow well defined data types as input and output and provide basic
> transformation logic.
> Having the possibility to choose, a user can specify the *format* option on
> an endpoint URI in order to specify the requested data type. Each component
> defines a set of supported data types and provides logic to convert to and
> from this data type.
> {{from("kafka:topic?format=avro").to("aws2-s3:bucketName?format=string")}}
> The example above lets the user choose one of the supported input/output data
> formats on the components kafka and aws2-s3. The components may offer
> specific logic to transform from/to the defined data type. Also there will be
> generic data type transformation logic that Camel already provides when
> converting types via TypeConverter.
> The idea is to provide multiple supported data types for components and let
> the component automatically apply transformation logic to/from the data type
> that the user has chosen.
> On the one hand there is the transformation EIP and Camel provides powerful
> route DSL to perform transformations from one data type to another. But in
> many cases the component itself knows best how to transform from/to the
> domain model data type.
> This is especially useful when dealing with components that use Java POJO
> objects as input/output. This way the user is able to deal with more common
> data types (e.g. String, Json) instead of having to know the domain model of
> the individual component.
> In particular this would be beneficial for Camel K and Kamelets (also see the
> discussions in https://github.com/apache/camel-k/issues/1980) where
> declarative YAML DSL is used to specify the route logic. In these declarative
> use cases the usage of custom Java processors to transform from one data type
> to another is not easily possible. Instead the components itself should
> provide predefined data type support and offer multiple types that the user
> may choose from.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18698) Add support for multiple data types on components
[
https://issues.apache.org/jira/browse/CAMEL-18698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631026#comment-17631026
]
Tadayoshi Sato commented on CAMEL-18698:
There are related tickets already about data types on components.
CAMEL-11132
CAMEL-17620
> Add support for multiple data types on components
> -
>
> Key: CAMEL-18698
> URL: https://issues.apache.org/jira/browse/CAMEL-18698
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Reporter: Christoph Deppisch
>Priority: Major
>
> Each component consumes/produces input and output data when processing the
> exchange as part of the route. Usually a component reads data from the
> exchange message (body and header) as input and produces specific message
> content as an output.
> The input and output of a component can be of various nature (e.g. Java POJO
> objects, Json objects, String, binary data, InputStream, etc.)
> In order to simplify the interrelationship between components each component
> should allow well defined data types as input and output and provide basic
> transformation logic.
> Having the possibility to choose, a user can specify the *format* option on
> an endpoint URI in order to specify the requested data type. Each component
> defines a set of supported data types and provides logic to convert to and
> from this data type.
> {{from("kafka:topic?format=avro").to("aws2-s3:bucketName?format=string")}}
> The example above lets the user choose one of the supported input/output data
> formats on the components kafka and aws2-s3. The components may offer
> specific logic to transform from/to the defined data type. Also there will be
> generic data type transformation logic that Camel already provides when
> converting types via TypeConverter.
> The idea is to provide multiple supported data types for components and let
> the component automatically apply transformation logic to/from the data type
> that the user has chosen.
> On the one hand there is the transformation EIP and Camel provides powerful
> route DSL to perform transformations from one data type to another. But in
> many cases the component itself knows best how to transform from/to the
> domain model data type.
> This is especially useful when dealing with components that use Java POJO
> objects as input/output. This way the user is able to deal with more common
> data types (e.g. String, Json) instead of having to know the domain model of
> the individual component.
> In particular this would be beneficial for Camel K and Kamelets (also see the
> discussions in https://github.com/apache/camel-k/issues/1980) where
> declarative YAML DSL is used to specify the route logic. In these declarative
> use cases the usage of custom Java processors to transform from one data type
> to another is not easily possible. Instead the components itself should
> provide predefined data type support and offer multiple types that the user
> may choose from.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18673) camel-jbang - Provide shell completions for camel CLI
Tadayoshi Sato created CAMEL-18673:
--
Summary: camel-jbang - Provide shell completions for camel CLI
Key: CAMEL-18673
URL: https://issues.apache.org/jira/browse/CAMEL-18673
Project: Camel
Issue Type: New Feature
Components: camel-jbang
Affects Versions: 3.19.0
Reporter: Tadayoshi Sato
camel-jbang is a great tool to interact with Camel applications. It would be
even greater if it provides a command that generates completion scripts for the
popular shells such as bash, zsh, etc.
{code}
$ camel completion [bash|zsh|...]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17620) Document data type in body from the endpoints of each component
[ https://issues.apache.org/jira/browse/CAMEL-17620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489272#comment-17489272 ] Tadayoshi Sato commented on CAMEL-17620: Yes, agreed. We should start from Kamelets docs. > Document data type in body from the endpoints of each component > --- > > Key: CAMEL-17620 > URL: https://issues.apache.org/jira/browse/CAMEL-17620 > Project: Camel > Issue Type: Task > Components: documentation >Affects Versions: 3.15.0 >Reporter: Tadayoshi Sato >Priority: Major > > I sometimes see users complaining that it is not clear about what data type > they can expect from an endpoint for further processing in the route. > The endpoint parameters are well documented already but the data type each > endpoint should return is rarely documented, for example: > https://camel.apache.org/components/3.15.x/twitter-search-component.html > It would be great if we can find some way to automate the documentation of > the data type an endpoint returns, or at least document them manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (CAMEL-12823) Create a LINE component
[ https://issues.apache.org/jira/browse/CAMEL-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato closed CAMEL-12823. -- Resolution: Won't Do > Create a LINE component > --- > > Key: CAMEL-12823 > URL: https://issues.apache.org/jira/browse/CAMEL-12823 > Project: Camel > Issue Type: New Feature >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: Future > > > [LINE|https://developers.line.me/en/] is the most popular mobile messaging > service in Japan. I will try to create a component for handling the SDKs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-12823) Create a LINE component
[ https://issues.apache.org/jira/browse/CAMEL-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489247#comment-17489247 ] Tadayoshi Sato commented on CAMEL-12823: At this moment I lost interest in developing a component for that service. Let me close it. > Create a LINE component > --- > > Key: CAMEL-12823 > URL: https://issues.apache.org/jira/browse/CAMEL-12823 > Project: Camel > Issue Type: New Feature >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Minor > Fix For: Future > > > [LINE|https://developers.line.me/en/] is the most popular mobile messaging > service in Japan. I will try to create a component for handling the SDKs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17620) Document data type in body from the endpoints of each component
Tadayoshi Sato created CAMEL-17620: -- Summary: Document data type in body from the endpoints of each component Key: CAMEL-17620 URL: https://issues.apache.org/jira/browse/CAMEL-17620 Project: Camel Issue Type: Task Components: documentation Affects Versions: 3.15.0 Reporter: Tadayoshi Sato I sometimes see users complaining that it is not clear about what data type they can expect from an endpoint for further processing in the route. The endpoint parameters are well documented already but the data type each endpoint should return is rarely documented, for example: https://camel.apache.org/components/3.15.x/twitter-search-component.html It would be great if we can find some way to automate the documentation of the data type an endpoint returns, or at least document them manually. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CAMEL-16813) RAW function - escape ) character
[
https://issues.apache.org/jira/browse/CAMEL-16813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387065#comment-17387065
]
Tadayoshi Sato edited comment on CAMEL-16813 at 7/26/21, 5:39 AM:
--
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like:
{code:java}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code:java}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW\{...} instead of RAW(...).
{code:java}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
was (Author: tadayosi):
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like:
{code:java}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code:java}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW\\{...\} instead of RAW(...).
{code:java}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
> RAW function - escape ) character
> -
>
> Key: CAMEL-16813
> URL: https://issues.apache.org/jira/browse/CAMEL-16813
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Pasquale Congiusti
>Priority: Major
>
> We've been reported a possible bug when using the RAW function including a )
> character. This is interpreted as closing the RAW function, though it may be
> part of the argument.
> As an example:
> {code}
> from("sftp:testserver/../testdir/?password=RAW(se+re?t)&23)")
> {code}
> Will fail as the function will take only *se+re?t* as an argument. I wonder
> if there is any escape character and if not, I think it makes sense to
> include all the text until the last ) character.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16813) RAW function - escape ) character
[
https://issues.apache.org/jira/browse/CAMEL-16813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387065#comment-17387065
]
Tadayoshi Sato edited comment on CAMEL-16813 at 7/26/21, 5:38 AM:
--
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like:
{code:java}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code:java}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW\\{...\} instead of RAW(...).
{code:java}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
was (Author: tadayosi):
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like:
{code:java}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code:java}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW
{...}
instead of RAW(...).
{code:java}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
> RAW function - escape ) character
> -
>
> Key: CAMEL-16813
> URL: https://issues.apache.org/jira/browse/CAMEL-16813
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Pasquale Congiusti
>Priority: Major
>
> We've been reported a possible bug when using the RAW function including a )
> character. This is interpreted as closing the RAW function, though it may be
> part of the argument.
> As an example:
> {code}
> from("sftp:testserver/../testdir/?password=RAW(se+re?t)&23)")
> {code}
> Will fail as the function will take only *se+re?t* as an argument. I wonder
> if there is any escape character and if not, I think it makes sense to
> include all the text until the last ) character.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-16813) RAW function - escape ) character
[
https://issues.apache.org/jira/browse/CAMEL-16813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387065#comment-17387065
]
Tadayoshi Sato edited comment on CAMEL-16813 at 7/26/21, 5:38 AM:
--
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like:
{code:java}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code:java}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW
{...}
instead of RAW(...).
{code:java}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
was (Author: tadayosi):
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like your case:
{code}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW{...} instead of RAW(...).
{code}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
> RAW function - escape ) character
> -
>
> Key: CAMEL-16813
> URL: https://issues.apache.org/jira/browse/CAMEL-16813
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Pasquale Congiusti
>Priority: Major
>
> We've been reported a possible bug when using the RAW function including a )
> character. This is interpreted as closing the RAW function, though it may be
> part of the argument.
> As an example:
> {code}
> from("sftp:testserver/../testdir/?password=RAW(se+re?t)&23)")
> {code}
> Will fail as the function will take only *se+re?t* as an argument. I wonder
> if there is any escape character and if not, I think it makes sense to
> include all the text until the last ) character.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-16813) RAW function - escape ) character
[
https://issues.apache.org/jira/browse/CAMEL-16813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17387065#comment-17387065
]
Tadayoshi Sato commented on CAMEL-16813:
[~squakez] As I sent to the user ML, I don't think this is a bug. If you use
RAW(...) and ")&" in the middle like your case:
{code}
?password=RAW(41))
{code}
there should be no way to syntactically parse the query uniquely. Parsing it as
a single "password" key with value "41)" is a valid way, but also parsing
it as two params of password = "41" and no value key "fail)" can be valid.
Let's see another example. How do we parse this query?
{code}
?param1=RAW(abc)=RAW(def)
{code}
Is it param1 = "abc)=RAW(def)" or param1 = "abc" and param2 = "def"?
With CAMEL-12982 what we provide for such a case as using a password containing
")&" is to use RAW{...} instead of RAW(...).
{code}
?password=RAW{41)}
{code}
For more detail on RAW() vs RAW{} I wrote an explanation here:
https://issues.apache.org/jira/browse/CAMEL-12982?focusedCommentId=16744700=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16744700
> RAW function - escape ) character
> -
>
> Key: CAMEL-16813
> URL: https://issues.apache.org/jira/browse/CAMEL-16813
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Pasquale Congiusti
>Priority: Major
>
> We've been reported a possible bug when using the RAW function including a )
> character. This is interpreted as closing the RAW function, though it may be
> part of the argument.
> As an example:
> {code}
> from("sftp:testserver/../testdir/?password=RAW(se+re?t)&23)")
> {code}
> Will fail as the function will take only *se+re?t* as an argument. I wonder
> if there is any escape character and if not, I think it makes sense to
> include all the text until the last ) character.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-16517) camel-bindy - Doc doesn't reflect FixeLengthRecord annotation changes after CAMEL-5958
[
https://issues.apache.org/jira/browse/CAMEL-16517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-16517 started by Tadayoshi Sato.
--
> camel-bindy - Doc doesn't reflect FixeLengthRecord annotation changes after
> CAMEL-5958
> --
>
> Key: CAMEL-16517
> URL: https://issues.apache.org/jira/browse/CAMEL-16517
> Project: Camel
> Issue Type: Task
> Components: camel-bindy, documentation
>Affects Versions: 3.9.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.10.0
>
>
> https://camel.apache.org/components/3.9.x/dataformats/bindy-dataformat.html
> For instance, the doc still shows {{hasHeader}} / {{hasFooter}} /
> {{isHeader}} / {{isFooter}}, etc. as annotation parameters even though they
> are no longer available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-16532) CXFConsumer unexpectedly unregistered
[
https://issues.apache.org/jira/browse/CAMEL-16532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17327085#comment-17327085
]
Tadayoshi Sato commented on CAMEL-16532:
As I said in CAMEL-10914, having an identical CXF endpoint at multiple route
{{from}} steps sounds like a application configuration bug, rather than a bug
in Camel. Even if somehow the issue described here is cleared, it should fail
to load eventually.
> CXFConsumer unexpectedly unregistered
> -
>
> Key: CAMEL-16532
> URL: https://issues.apache.org/jira/browse/CAMEL-16532
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.24.2, 3.9.0
>Reporter: Manuel Shenavai
>Priority: Minor
>
> This issue is related to CAMEL-10914.
> Desscription:
> Route1 - CXFConsumer with endpoint address /test is already running
> Route2 - Gets started with CXFConsumer with same endpoint /test
> The expected behavior: Route2 startup fails (endpoint already registered on
> address). Route1 keeps running.
> Expected error on Route2 (endpoint already registered on address):
>
> [https://github.com/apache/cxf/blob/master/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/SoapBindingFactory.java#L918]
> Due to the change in CAMEL-10914, server.destroy() will be called after
> failed startup:
>
> [https://github.com/tadayosi/camel/commit/6d31d169dc17138ed02ad1164a4b2209729677fc#diff-174b6ca7cb178d3dc464aa9355d148d95fc0a3ad3f7edb60f0293fac988d3e05R100]
> And it will eventually unregister the route:
>
> [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/endpoint/ServerImpl.java#L191]
> Observed behavior:
> After failed startup of Route2, Route1 is not registered anymore (HTTP 404
> when trying to call /test). I could not reproduce this with embedded Jetty,
> but we experience this with tomcat on production.
> Do you have any suggestion how this could be reproduced in a test using
> tomcat? Is there a simple way to replace jetty with tomcat?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-10914) CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
[
https://issues.apache.org/jira/browse/CAMEL-10914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17325493#comment-17325493
]
Tadayoshi Sato commented on CAMEL-10914:
[~mash-sap] Hmm, my first impression is that you should just not try to
register the same endpoint twice. Having duplicate consumers with exact same
endpoint URI sounds application configuration issue rather than a bug with
Camel.
That said, I'd file another JIRA with link to this one as 'is caused by' and
discuss your issue further there.
> CxfConsumer doesn't clean up the CXF endpoint MBean upon stop
> -
>
> Key: CAMEL-10914
> URL: https://issues.apache.org/jira/browse/CAMEL-10914
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.18.2
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
> Attachments: camel-cxf-hawtio.zip
>
>
> {{CxfConsumer}}'s {{doStop()}} method just does {{server.stop()}} and not
> {{server.destroy()}}:
> {code:java}
> protected void doStop() throws Exception {
> server.stop();
> super.doStop();
> }
> {code}
> This leads to a growing number of dangling endpoint MBeans on CXF side which
> are never used.
> To reproduce the issue, extract the attached reproducer
> {{camel-cxf-hawtio.zip}} and do the following steps:
> # Run the following command:
> {code}
> $ mvn hawtio:camel
> {code}
> # Access hawtio Camel tab [http://localhost:8080/hawtio/]. Start and stop the
> route {{cxf-greeting}} several times.
> # Go to hawtio JMX tab and check CXF endpoint MBeans are growing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16517) camel-bindy - Doc doesn't reflect FixeLengthRecord annotation changes after CAMEL-5958
Tadayoshi Sato created CAMEL-16517:
--
Summary: camel-bindy - Doc doesn't reflect FixeLengthRecord
annotation changes after CAMEL-5958
Key: CAMEL-16517
URL: https://issues.apache.org/jira/browse/CAMEL-16517
Project: Camel
Issue Type: Task
Components: camel-bindy, documentation
Affects Versions: 3.9.0
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
https://camel.apache.org/components/3.9.x/dataformats/bindy-dataformat.html
For instance, the doc still shows {{hasHeader}} / {{hasFooter}} / {{isHeader}}
/ {{isFooter}}, etc. as annotation parameters even though they are no longer
available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-16259) Karaf examples don't get deployed
[
https://issues.apache.org/jira/browse/CAMEL-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-16259.
Resolution: Fixed
> Karaf examples don't get deployed
> -
>
> Key: CAMEL-16259
> URL: https://issues.apache.org/jira/browse/CAMEL-16259
> Project: Camel
> Issue Type: Task
> Components: examples, karaf
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 3.10.0
>
>
> [Karaf example jars|https://github.com/apache/camel-karaf-examples] should
> have OSGi-related metadata such as {{Import-Package}} but they don't. Using
> [bnd|https://bnd.bndtools.org/]:
> {code:java}
> $ bnd
> camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
>
> Build-Jdk-Spec 11
> Created-By Maven Jar Plugin 3.2.0
> Implementation-TitleCamel :: Example :: Servlet :: OSGi
> Implementation-Vendor The Apache Software Foundation
> Implementation-Version 3.9.0-SNAPSHOT
> Manifest-Version1.0
> Specification-Title Camel :: Example :: Servlet :: OSGi
> Specification-VendorThe Apache Software Foundation
> Specification-Version 3.9
> {code}
> This causes the following deploy command on Karaf to fail:
> {code:java}
> install -s
> mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
> {code}
> Checking Camel 2.x (which still worked):
> {code:java}
> $ bnd
> examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
>
> Bnd-LastModified1568357813343
> Build-Jdk 1.8.0_222
> Built-Bytasato
> Bundle-BlueprintOSGI-INF/blueprint/camel.xml
> Bundle-Description An example using Servlet REST with
> OSGi Blueprint
> Bundle-DocURL https://www.apache.org/
> Bundle-License
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion 2
> Bundle-Name camel-example-servlet-rest-blueprint
> Bundle-SymbolicName camel-example-servlet-rest-blueprint
> Bundle-Vendor The Apache Software Foundation
> Bundle-Version 2.25.0.SNAPSHOT
> Created-By Apache Maven Bundle Plugin
> Export-Package
> org.apache.camel.example.rest;version="2.25.0.SNAPSHOT"
> Implementation-TitleCamel :: Example :: Servlet REST
> Blueprint
> Implementation-URL
> http://camel.apache.org/camel-parent/examples/camel-example-servlet-rest-blueprint
> Implementation-Vendor The Apache Software Foundation
> Implementation-Vendor-Idorg.apache.camel.example
> Implementation-Version 2.25.0-SNAPSHOT
> Import-Package
> org.apache.camel.component.servlet.osgi;version="[2.25,3)"
>
> org.apache.camel.component.servlet;version="[2.25,3)"
>
> org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> org.osgi.service.http
> Import-Service
> org.osgi.service.http.HttpService;multiple:=false
> Karaf-Info
> Camel;camel-example-servlet-rest-blueprint=2.25.0-SNAPSHOT
> Manifest-Version1.0
> Require-Capability
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Specification-Title Camel :: Example :: Servlet REST
> Blueprint
> Specification-VendorThe Apache Software Foundation
> Specification-Version 2.25.0-SNAPSHOT
> ToolBnd-3.5.0.201709291849
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-16259) Karaf examples don't get deployed
[
https://issues.apache.org/jira/browse/CAMEL-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-16259 started by Tadayoshi Sato.
--
> Karaf examples don't get deployed
> -
>
> Key: CAMEL-16259
> URL: https://issues.apache.org/jira/browse/CAMEL-16259
> Project: Camel
> Issue Type: Task
> Components: examples, karaf
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 3.10.0
>
>
> [Karaf example jars|https://github.com/apache/camel-karaf-examples] should
> have OSGi-related metadata such as {{Import-Package}} but they don't. Using
> [bnd|https://bnd.bndtools.org/]:
> {code:java}
> $ bnd
> camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
>
> Build-Jdk-Spec 11
> Created-By Maven Jar Plugin 3.2.0
> Implementation-TitleCamel :: Example :: Servlet :: OSGi
> Implementation-Vendor The Apache Software Foundation
> Implementation-Version 3.9.0-SNAPSHOT
> Manifest-Version1.0
> Specification-Title Camel :: Example :: Servlet :: OSGi
> Specification-VendorThe Apache Software Foundation
> Specification-Version 3.9
> {code}
> This causes the following deploy command on Karaf to fail:
> {code:java}
> install -s
> mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
> {code}
> Checking Camel 2.x (which still worked):
> {code:java}
> $ bnd
> examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
>
> Bnd-LastModified1568357813343
> Build-Jdk 1.8.0_222
> Built-Bytasato
> Bundle-BlueprintOSGI-INF/blueprint/camel.xml
> Bundle-Description An example using Servlet REST with
> OSGi Blueprint
> Bundle-DocURL https://www.apache.org/
> Bundle-License
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion 2
> Bundle-Name camel-example-servlet-rest-blueprint
> Bundle-SymbolicName camel-example-servlet-rest-blueprint
> Bundle-Vendor The Apache Software Foundation
> Bundle-Version 2.25.0.SNAPSHOT
> Created-By Apache Maven Bundle Plugin
> Export-Package
> org.apache.camel.example.rest;version="2.25.0.SNAPSHOT"
> Implementation-TitleCamel :: Example :: Servlet REST
> Blueprint
> Implementation-URL
> http://camel.apache.org/camel-parent/examples/camel-example-servlet-rest-blueprint
> Implementation-Vendor The Apache Software Foundation
> Implementation-Vendor-Idorg.apache.camel.example
> Implementation-Version 2.25.0-SNAPSHOT
> Import-Package
> org.apache.camel.component.servlet.osgi;version="[2.25,3)"
>
> org.apache.camel.component.servlet;version="[2.25,3)"
>
> org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> org.osgi.service.http
> Import-Service
> org.osgi.service.http.HttpService;multiple:=false
> Karaf-Info
> Camel;camel-example-servlet-rest-blueprint=2.25.0-SNAPSHOT
> Manifest-Version1.0
> Require-Capability
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Specification-Title Camel :: Example :: Servlet REST
> Blueprint
> Specification-VendorThe Apache Software Foundation
> Specification-Version 2.25.0-SNAPSHOT
> ToolBnd-3.5.0.201709291849
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-16280) NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
[
https://issues.apache.org/jira/browse/CAMEL-16280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-16280 started by Tadayoshi Sato.
--
> NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
> -
>
> Key: CAMEL-16280
> URL: https://issues.apache.org/jira/browse/CAMEL-16280
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Attachments: camel-netty.jsh
>
>
> Run this jbang script:
> {code:java}
> ///usr/bin/env jbang "$0" "$@" ; exit $?
> //DEPS org.apache.camel:camel-core-engine:3.8.0
> //DEPS org.apache.camel:camel-main:3.8.0
> //DEPS org.apache.camel:camel-stream:3.8.0
> //DEPS org.apache.camel:camel-netty:3.8.0
> //DEPS org.slf4j:slf4j-nop:1.7.25
> import java.util.*;
> import org.apache.camel.*;
> import org.apache.camel.spi.*;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.main.Main;
> import org.apache.camel.component.netty.*;
> Main main = new Main();
> main.configure().addRoutesBuilder(new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> EndpointUriFactory factory =
> getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
> Map config = Map.of(
> "protocol", "tcp",
> "host", "localhost",
> "port",
> );
> String uri = factory.buildUri("netty", config, false);
> System.out.println("uri = " + uri);
> from(uri).to("stream:out");
> //from("netty:tcp://localhost:").to("stream:out"); // this is OK
> }
> });
> main.run();
> {code}
> and you'll get the following error:
> {code}
> $ ./camel-netty.jsh
> uri = netty:tcp:localhost:
> Exception java.lang.IllegalArgumentException: hostname can't be null
> at InetSocketAddress.checkHost (InetSocketAddress.java:149)
> at InetSocketAddress. (InetSocketAddress.java:216)
> at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
> (SingleTCPNettyServerBootstrapFactory.java:184)
> at SingleTCPNettyServerBootstrapFactory.doStart
> (SingleTCPNettyServerBootstrapFactory.java:113)
> at BaseService.start (BaseService.java:115)
> at ServiceHelper.startService (ServiceHelper.java:84)
> at NettyConsumer.doStart (NettyConsumer.java:75)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.startService (AbstractCamelContext.java:3446)
> at InternalRouteStartupManager.doStartOrResumeRouteConsumers
> (InternalRouteStartupManager.java:401)
> at InternalRouteStartupManager.doStartRouteConsumers
> (InternalRouteStartupManager.java:319)
> at InternalRouteStartupManager.safelyStartRouteServices
> (InternalRouteStartupManager.java:213)
> at InternalRouteStartupManager.doStartOrResumeRoutes
> (InternalRouteStartupManager.java:147)
> at AbstractCamelContext.doStartCamel (AbstractCamelContext.java:3150)
> at AbstractCamelContext.doStartContext (AbstractCamelContext.java:2846)
> at AbstractCamelContext.doStart (AbstractCamelContext.java:2797)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.start (AbstractCamelContext.java:2492)
> at Main.doStart (Main.java:116)
> at BaseService.start (BaseService.java:115)
> at MainSupport.run (MainSupport.java:68)
> at (#9:1)
> {code}
> This issue is the root cause of this CKC issue:
> https://github.com/apache/camel-kafka-connector/issues/924
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16280) NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
[
https://issues.apache.org/jira/browse/CAMEL-16280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-16280:
---
Attachment: camel-netty.jsh
> NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
> -
>
> Key: CAMEL-16280
> URL: https://issues.apache.org/jira/browse/CAMEL-16280
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Attachments: camel-netty.jsh
>
>
> Run this jbang script:
> {code:java}
> ///usr/bin/env jbang "$0" "$@" ; exit $?
> //DEPS org.apache.camel:camel-core-engine:3.8.0
> //DEPS org.apache.camel:camel-main:3.8.0
> //DEPS org.apache.camel:camel-stream:3.8.0
> //DEPS org.apache.camel:camel-netty:3.8.0
> //DEPS org.slf4j:slf4j-nop:1.7.25
> import java.util.*;
> import org.apache.camel.*;
> import org.apache.camel.spi.*;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.main.Main;
> import org.apache.camel.component.netty.*;
> Main main = new Main();
> main.configure().addRoutesBuilder(new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> EndpointUriFactory factory =
> getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
> Map config = Map.of(
> "protocol", "tcp",
> "host", "localhost",
> "port",
> );
> String uri = factory.buildUri("netty", config, false);
> System.out.println("uri = " + uri);
> from(uri).to("stream:out");
> //from("netty:tcp://localhost:").to("stream:out"); // this is OK
> }
> });
> main.run();
> {code}
> and you'll get the following error:
> {code}
> $ ./camel-netty.jsh
> uri = netty:tcp:localhost:
> Exception java.lang.IllegalArgumentException: hostname can't be null
> at InetSocketAddress.checkHost (InetSocketAddress.java:149)
> at InetSocketAddress. (InetSocketAddress.java:216)
> at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
> (SingleTCPNettyServerBootstrapFactory.java:184)
> at SingleTCPNettyServerBootstrapFactory.doStart
> (SingleTCPNettyServerBootstrapFactory.java:113)
> at BaseService.start (BaseService.java:115)
> at ServiceHelper.startService (ServiceHelper.java:84)
> at NettyConsumer.doStart (NettyConsumer.java:75)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.startService (AbstractCamelContext.java:3446)
> at InternalRouteStartupManager.doStartOrResumeRouteConsumers
> (InternalRouteStartupManager.java:401)
> at InternalRouteStartupManager.doStartRouteConsumers
> (InternalRouteStartupManager.java:319)
> at InternalRouteStartupManager.safelyStartRouteServices
> (InternalRouteStartupManager.java:213)
> at InternalRouteStartupManager.doStartOrResumeRoutes
> (InternalRouteStartupManager.java:147)
> at AbstractCamelContext.doStartCamel (AbstractCamelContext.java:3150)
> at AbstractCamelContext.doStartContext (AbstractCamelContext.java:2846)
> at AbstractCamelContext.doStart (AbstractCamelContext.java:2797)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.start (AbstractCamelContext.java:2492)
> at Main.doStart (Main.java:116)
> at BaseService.start (BaseService.java:115)
> at MainSupport.run (MainSupport.java:68)
> at (#9:1)
> {code}
> This issue is the root cause of this CKC issue:
> https://github.com/apache/camel-kafka-connector/issues/924
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16280) NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
[
https://issues.apache.org/jira/browse/CAMEL-16280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-16280:
---
Description:
Run this jbang script:
{code:java}
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS org.apache.camel:camel-core-engine:3.8.0
//DEPS org.apache.camel:camel-main:3.8.0
//DEPS org.apache.camel:camel-stream:3.8.0
//DEPS org.apache.camel:camel-netty:3.8.0
//DEPS org.slf4j:slf4j-nop:1.7.25
import java.util.*;
import org.apache.camel.*;
import org.apache.camel.spi.*;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.main.Main;
import org.apache.camel.component.netty.*;
Main main = new Main();
main.configure().addRoutesBuilder(new RouteBuilder() {
@Override
public void configure() throws Exception {
EndpointUriFactory factory =
getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
Map config = Map.of(
"protocol", "tcp",
"host", "localhost",
"port",
);
String uri = factory.buildUri("netty", config, false);
System.out.println("uri = " + uri);
from(uri).to("stream:out");
//from("netty:tcp://localhost:").to("stream:out"); // this is OK
}
});
main.run();
{code}
and you'll get the following error:
{code}
$ ./camel-netty.jsh
uri = netty:tcp:localhost:
Exception java.lang.IllegalArgumentException: hostname can't be null
at InetSocketAddress.checkHost (InetSocketAddress.java:149)
at InetSocketAddress. (InetSocketAddress.java:216)
at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
(SingleTCPNettyServerBootstrapFactory.java:184)
at SingleTCPNettyServerBootstrapFactory.doStart
(SingleTCPNettyServerBootstrapFactory.java:113)
at BaseService.start (BaseService.java:115)
at ServiceHelper.startService (ServiceHelper.java:84)
at NettyConsumer.doStart (NettyConsumer.java:75)
at BaseService.start (BaseService.java:115)
at AbstractCamelContext.startService (AbstractCamelContext.java:3446)
at InternalRouteStartupManager.doStartOrResumeRouteConsumers
(InternalRouteStartupManager.java:401)
at InternalRouteStartupManager.doStartRouteConsumers
(InternalRouteStartupManager.java:319)
at InternalRouteStartupManager.safelyStartRouteServices
(InternalRouteStartupManager.java:213)
at InternalRouteStartupManager.doStartOrResumeRoutes
(InternalRouteStartupManager.java:147)
at AbstractCamelContext.doStartCamel (AbstractCamelContext.java:3150)
at AbstractCamelContext.doStartContext (AbstractCamelContext.java:2846)
at AbstractCamelContext.doStart (AbstractCamelContext.java:2797)
at BaseService.start (BaseService.java:115)
at AbstractCamelContext.start (AbstractCamelContext.java:2492)
at Main.doStart (Main.java:116)
at BaseService.start (BaseService.java:115)
at MainSupport.run (MainSupport.java:68)
at (#9:1)
{code}
This issue is the root cause of this CKC issue:
https://github.com/apache/camel-kafka-connector/issues/924
was:
Run this jbang script:
{code:java}
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS org.apache.camel:camel-core-engine:3.8.0
//DEPS org.apache.camel:camel-main:3.8.0
//DEPS org.apache.camel:camel-stream:3.8.0
//DEPS org.apache.camel:camel-netty:3.8.0
//DEPS org.slf4j:slf4j-nop:1.7.25
import java.util.*;
import org.apache.camel.*;
import org.apache.camel.spi.*;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.main.Main;
import org.apache.camel.component.netty.*;
Main main = new Main();
main.configure().addRoutesBuilder(new RouteBuilder() {
@Override
public void configure() throws Exception {
EndpointUriFactory factory =
getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
Map config = Map.of(
"protocol", "tcp",
"host", "localhost",
"port",
);
String uri = factory.buildUri("netty", config, false);
System.out.println("uri = " + uri);
from(uri).to("stream:out");
//from("netty:tcp://localhost:").to("stream:out");
}
});
main.run();
{code}
and you'll get the following error:
{code}
$ ./camel-netty.jsh
uri = netty:tcp:localhost:
Exception java.lang.IllegalArgumentException: hostname can't be null
at InetSocketAddress.checkHost (InetSocketAddress.java:149)
at InetSocketAddress. (InetSocketAddress.java:216)
at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
(SingleTCPNettyServerBootstrapFactory.java:184)
at SingleTCPNettyServerBootstrapFactory.doStart
(SingleTCPNettyServerBootstrapFactory.java:113)
at BaseService.start (BaseService.java:115)
at ServiceHelper.startService (ServiceHelper.java:84)
at NettyConsumer.doStart (NettyConsumer.java:75)
at BaseService.start (BaseService.java:115)
[jira] [Assigned] (CAMEL-16280) NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
[
https://issues.apache.org/jira/browse/CAMEL-16280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato reassigned CAMEL-16280:
--
Assignee: Tadayoshi Sato
> NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
> -
>
> Key: CAMEL-16280
> URL: https://issues.apache.org/jira/browse/CAMEL-16280
> Project: Camel
> Issue Type: Bug
> Components: camel-netty
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Run this jbang script:
> {code:java}
> ///usr/bin/env jbang "$0" "$@" ; exit $?
> //DEPS org.apache.camel:camel-core-engine:3.8.0
> //DEPS org.apache.camel:camel-main:3.8.0
> //DEPS org.apache.camel:camel-stream:3.8.0
> //DEPS org.apache.camel:camel-netty:3.8.0
> //DEPS org.slf4j:slf4j-nop:1.7.25
> import java.util.*;
> import org.apache.camel.*;
> import org.apache.camel.spi.*;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.main.Main;
> import org.apache.camel.component.netty.*;
> Main main = new Main();
> main.configure().addRoutesBuilder(new RouteBuilder() {
> @Override
> public void configure() throws Exception {
> EndpointUriFactory factory =
> getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
> Map config = Map.of(
> "protocol", "tcp",
> "host", "localhost",
> "port",
> );
> String uri = factory.buildUri("netty", config, false);
> System.out.println("uri = " + uri);
> from(uri).to("stream:out");
> //from("netty:tcp://localhost:").to("stream:out");
> }
> });
> main.run();
> {code}
> and you'll get the following error:
> {code}
> $ ./camel-netty.jsh
> uri = netty:tcp:localhost:
> Exception java.lang.IllegalArgumentException: hostname can't be null
> at InetSocketAddress.checkHost (InetSocketAddress.java:149)
> at InetSocketAddress. (InetSocketAddress.java:216)
> at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
> (SingleTCPNettyServerBootstrapFactory.java:184)
> at SingleTCPNettyServerBootstrapFactory.doStart
> (SingleTCPNettyServerBootstrapFactory.java:113)
> at BaseService.start (BaseService.java:115)
> at ServiceHelper.startService (ServiceHelper.java:84)
> at NettyConsumer.doStart (NettyConsumer.java:75)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.startService (AbstractCamelContext.java:3446)
> at InternalRouteStartupManager.doStartOrResumeRouteConsumers
> (InternalRouteStartupManager.java:401)
> at InternalRouteStartupManager.doStartRouteConsumers
> (InternalRouteStartupManager.java:319)
> at InternalRouteStartupManager.safelyStartRouteServices
> (InternalRouteStartupManager.java:213)
> at InternalRouteStartupManager.doStartOrResumeRoutes
> (InternalRouteStartupManager.java:147)
> at AbstractCamelContext.doStartCamel (AbstractCamelContext.java:3150)
> at AbstractCamelContext.doStartContext (AbstractCamelContext.java:2846)
> at AbstractCamelContext.doStart (AbstractCamelContext.java:2797)
> at BaseService.start (BaseService.java:115)
> at AbstractCamelContext.start (AbstractCamelContext.java:2492)
> at Main.doStart (Main.java:116)
> at BaseService.start (BaseService.java:115)
> at MainSupport.run (MainSupport.java:68)
> at (#9:1)
> {code}
> This issue is the root cause of this CKC issue:
> https://github.com/apache/camel-kafka-connector/issues/924
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16280) NettyEndpointUriFactory#buildUri() not compatible with Netty endpoint URL
Tadayoshi Sato created CAMEL-16280:
--
Summary: NettyEndpointUriFactory#buildUri() not compatible with
Netty endpoint URL
Key: CAMEL-16280
URL: https://issues.apache.org/jira/browse/CAMEL-16280
Project: Camel
Issue Type: Bug
Components: camel-netty
Affects Versions: 3.8.0
Reporter: Tadayoshi Sato
Run this jbang script:
{code:java}
///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS org.apache.camel:camel-core-engine:3.8.0
//DEPS org.apache.camel:camel-main:3.8.0
//DEPS org.apache.camel:camel-stream:3.8.0
//DEPS org.apache.camel:camel-netty:3.8.0
//DEPS org.slf4j:slf4j-nop:1.7.25
import java.util.*;
import org.apache.camel.*;
import org.apache.camel.spi.*;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.main.Main;
import org.apache.camel.component.netty.*;
Main main = new Main();
main.configure().addRoutesBuilder(new RouteBuilder() {
@Override
public void configure() throws Exception {
EndpointUriFactory factory =
getContext().adapt(ExtendedCamelContext.class).getEndpointUriFactory("netty");
Map config = Map.of(
"protocol", "tcp",
"host", "localhost",
"port",
);
String uri = factory.buildUri("netty", config, false);
System.out.println("uri = " + uri);
from(uri).to("stream:out");
//from("netty:tcp://localhost:").to("stream:out");
}
});
main.run();
{code}
and you'll get the following error:
{code}
$ ./camel-netty.jsh
uri = netty:tcp:localhost:
Exception java.lang.IllegalArgumentException: hostname can't be null
at InetSocketAddress.checkHost (InetSocketAddress.java:149)
at InetSocketAddress. (InetSocketAddress.java:216)
at SingleTCPNettyServerBootstrapFactory.startServerBootstrap
(SingleTCPNettyServerBootstrapFactory.java:184)
at SingleTCPNettyServerBootstrapFactory.doStart
(SingleTCPNettyServerBootstrapFactory.java:113)
at BaseService.start (BaseService.java:115)
at ServiceHelper.startService (ServiceHelper.java:84)
at NettyConsumer.doStart (NettyConsumer.java:75)
at BaseService.start (BaseService.java:115)
at AbstractCamelContext.startService (AbstractCamelContext.java:3446)
at InternalRouteStartupManager.doStartOrResumeRouteConsumers
(InternalRouteStartupManager.java:401)
at InternalRouteStartupManager.doStartRouteConsumers
(InternalRouteStartupManager.java:319)
at InternalRouteStartupManager.safelyStartRouteServices
(InternalRouteStartupManager.java:213)
at InternalRouteStartupManager.doStartOrResumeRoutes
(InternalRouteStartupManager.java:147)
at AbstractCamelContext.doStartCamel (AbstractCamelContext.java:3150)
at AbstractCamelContext.doStartContext (AbstractCamelContext.java:2846)
at AbstractCamelContext.doStart (AbstractCamelContext.java:2797)
at BaseService.start (BaseService.java:115)
at AbstractCamelContext.start (AbstractCamelContext.java:2492)
at Main.doStart (Main.java:116)
at BaseService.start (BaseService.java:115)
at MainSupport.run (MainSupport.java:68)
at (#9:1)
{code}
This issue is the root cause of this CKC issue:
https://github.com/apache/camel-kafka-connector/issues/924
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CAMEL-16259) Karaf examples don't get deployed
[
https://issues.apache.org/jira/browse/CAMEL-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato reassigned CAMEL-16259:
--
Assignee: Tadayoshi Sato
> Karaf examples don't get deployed
> -
>
> Key: CAMEL-16259
> URL: https://issues.apache.org/jira/browse/CAMEL-16259
> Project: Camel
> Issue Type: Task
> Components: examples, karaf
>Affects Versions: 3.8.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Minor
> Fix For: 3.9.0
>
>
> [Karaf example jars|https://github.com/apache/camel-karaf-examples] should
> have OSGi-related metadata such as {{Import-Package}} but they don't. Using
> [bnd|https://bnd.bndtools.org/]:
> {code:java}
> $ bnd
> camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
>
> Build-Jdk-Spec 11
> Created-By Maven Jar Plugin 3.2.0
> Implementation-TitleCamel :: Example :: Servlet :: OSGi
> Implementation-Vendor The Apache Software Foundation
> Implementation-Version 3.9.0-SNAPSHOT
> Manifest-Version1.0
> Specification-Title Camel :: Example :: Servlet :: OSGi
> Specification-VendorThe Apache Software Foundation
> Specification-Version 3.9
> {code}
> This causes the following deploy command on Karaf to fail:
> {code:java}
> install -s
> mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
> {code}
> Checking Camel 2.x (which still worked):
> {code:java}
> $ bnd
> examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
>
> Bnd-LastModified1568357813343
> Build-Jdk 1.8.0_222
> Built-Bytasato
> Bundle-BlueprintOSGI-INF/blueprint/camel.xml
> Bundle-Description An example using Servlet REST with
> OSGi Blueprint
> Bundle-DocURL https://www.apache.org/
> Bundle-License
> https://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion 2
> Bundle-Name camel-example-servlet-rest-blueprint
> Bundle-SymbolicName camel-example-servlet-rest-blueprint
> Bundle-Vendor The Apache Software Foundation
> Bundle-Version 2.25.0.SNAPSHOT
> Created-By Apache Maven Bundle Plugin
> Export-Package
> org.apache.camel.example.rest;version="2.25.0.SNAPSHOT"
> Implementation-TitleCamel :: Example :: Servlet REST
> Blueprint
> Implementation-URL
> http://camel.apache.org/camel-parent/examples/camel-example-servlet-rest-blueprint
> Implementation-Vendor The Apache Software Foundation
> Implementation-Vendor-Idorg.apache.camel.example
> Implementation-Version 2.25.0-SNAPSHOT
> Import-Package
> org.apache.camel.component.servlet.osgi;version="[2.25,3)"
>
> org.apache.camel.component.servlet;version="[2.25,3)"
>
> org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
> org.osgi.service.http
> Import-Service
> org.osgi.service.http.HttpService;multiple:=false
> Karaf-Info
> Camel;camel-example-servlet-rest-blueprint=2.25.0-SNAPSHOT
> Manifest-Version1.0
> Require-Capability
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Specification-Title Camel :: Example :: Servlet REST
> Blueprint
> Specification-VendorThe Apache Software Foundation
> Specification-Version 2.25.0-SNAPSHOT
> ToolBnd-3.5.0.201709291849
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16259) Karaf examples don't get deployed
[
https://issues.apache.org/jira/browse/CAMEL-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-16259:
---
Description:
[Karaf example jars|https://github.com/apache/camel-karaf-examples] should have
OSGi-related metadata such as {{Import-Package}} but they don't. Using
[bnd|https://bnd.bndtools.org/]:
{code:java}
$ bnd
camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
Build-Jdk-Spec 11
Created-By Maven Jar Plugin 3.2.0
Implementation-TitleCamel :: Example :: Servlet :: OSGi
Implementation-Vendor The Apache Software Foundation
Implementation-Version 3.9.0-SNAPSHOT
Manifest-Version1.0
Specification-Title Camel :: Example :: Servlet :: OSGi
Specification-VendorThe Apache Software Foundation
Specification-Version 3.9
{code}
This causes the following deploy command on Karaf to fail:
{code:java}
install -s
mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
{code}
Checking Camel 2.x (which still worked):
{code:java}
$ bnd
examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
Bnd-LastModified1568357813343
Build-Jdk 1.8.0_222
Built-Bytasato
Bundle-BlueprintOSGI-INF/blueprint/camel.xml
Bundle-Description An example using Servlet REST with OSGi
Blueprint
Bundle-DocURL https://www.apache.org/
Bundle-License
https://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion 2
Bundle-Name camel-example-servlet-rest-blueprint
Bundle-SymbolicName camel-example-servlet-rest-blueprint
Bundle-Vendor The Apache Software Foundation
Bundle-Version 2.25.0.SNAPSHOT
Created-By Apache Maven Bundle Plugin
Export-Package
org.apache.camel.example.rest;version="2.25.0.SNAPSHOT"
Implementation-TitleCamel :: Example :: Servlet REST
Blueprint
Implementation-URL
http://camel.apache.org/camel-parent/examples/camel-example-servlet-rest-blueprint
Implementation-Vendor The Apache Software Foundation
Implementation-Vendor-Idorg.apache.camel.example
Implementation-Version 2.25.0-SNAPSHOT
Import-Package
org.apache.camel.component.servlet.osgi;version="[2.25,3)"
org.apache.camel.component.servlet;version="[2.25,3)"
org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
org.osgi.service.http
Import-Service
org.osgi.service.http.HttpService;multiple:=false
Karaf-Info
Camel;camel-example-servlet-rest-blueprint=2.25.0-SNAPSHOT
Manifest-Version1.0
Require-Capability
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Specification-Title Camel :: Example :: Servlet REST
Blueprint
Specification-VendorThe Apache Software Foundation
Specification-Version 2.25.0-SNAPSHOT
ToolBnd-3.5.0.201709291849
{code}
was:
Karaf example jars should have OSGi-related metadata such as {{Import-Package}}
but they don't. Using [bnd|https://bnd.bndtools.org/]:
{code}
$ bnd
camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
Build-Jdk-Spec 11
Created-By Maven Jar Plugin 3.2.0
Implementation-TitleCamel :: Example :: Servlet :: OSGi
Implementation-Vendor The Apache Software Foundation
Implementation-Version 3.9.0-SNAPSHOT
Manifest-Version1.0
Specification-Title Camel :: Example :: Servlet :: OSGi
Specification-VendorThe Apache Software Foundation
Specification-Version 3.9
{code}
This causes the following deploy command on Karaf to fail:
{code}
install -s
mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
{code}
Checking Camel 2.x (which still worked):
{code}
$ bnd
examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
Bnd-LastModified1568357813343
Build-Jdk 1.8.0_222
Built-By
[jira] [Created] (CAMEL-16259) Karaf examples don't get deployed
Tadayoshi Sato created CAMEL-16259:
--
Summary: Karaf examples don't get deployed
Key: CAMEL-16259
URL: https://issues.apache.org/jira/browse/CAMEL-16259
Project: Camel
Issue Type: Bug
Components: examples, karaf
Affects Versions: 3.8.0
Reporter: Tadayoshi Sato
Karaf example jars should have OSGi-related metadata such as {{Import-Package}}
but they don't. Using [bnd|https://bnd.bndtools.org/]:
{code}
$ bnd
camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-3.9.0-SNAPSHOT.jar
Build-Jdk-Spec 11
Created-By Maven Jar Plugin 3.2.0
Implementation-TitleCamel :: Example :: Servlet :: OSGi
Implementation-Vendor The Apache Software Foundation
Implementation-Version 3.9.0-SNAPSHOT
Manifest-Version1.0
Specification-Title Camel :: Example :: Servlet :: OSGi
Specification-VendorThe Apache Software Foundation
Specification-Version 3.9
{code}
This causes the following deploy command on Karaf to fail:
{code}
install -s
mvn:org.apache.camel.example/camel-example-servlet-rest-blueprint/${camel.version}
{code}
Checking Camel 2.x (which still worked):
{code}
$ bnd
examples/camel-example-servlet-rest-blueprint/target/camel-example-servlet-rest-blueprint-2.25.0-SNAPSHOT.jar
Bnd-LastModified1568357813343
Build-Jdk 1.8.0_222
Built-Bytasato
Bundle-BlueprintOSGI-INF/blueprint/camel.xml
Bundle-Description An example using Servlet REST with OSGi
Blueprint
Bundle-DocURL https://www.apache.org/
Bundle-License
https://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion 2
Bundle-Name camel-example-servlet-rest-blueprint
Bundle-SymbolicName camel-example-servlet-rest-blueprint
Bundle-Vendor The Apache Software Foundation
Bundle-Version 2.25.0.SNAPSHOT
Created-By Apache Maven Bundle Plugin
Export-Package
org.apache.camel.example.rest;version="2.25.0.SNAPSHOT"
Implementation-TitleCamel :: Example :: Servlet REST
Blueprint
Implementation-URL
http://camel.apache.org/camel-parent/examples/camel-example-servlet-rest-blueprint
Implementation-Vendor The Apache Software Foundation
Implementation-Vendor-Idorg.apache.camel.example
Implementation-Version 2.25.0-SNAPSHOT
Import-Package
org.apache.camel.component.servlet.osgi;version="[2.25,3)"
org.apache.camel.component.servlet;version="[2.25,3)"
org.osgi.service.blueprint;version="[1.0.0,2.0.0)"
org.osgi.service.http
Import-Service
org.osgi.service.http.HttpService;multiple:=false
Karaf-Info
Camel;camel-example-servlet-rest-blueprint=2.25.0-SNAPSHOT
Manifest-Version1.0
Require-Capability
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Specification-Title Camel :: Example :: Servlet REST
Blueprint
Specification-VendorThe Apache Software Foundation
Specification-Version 2.25.0-SNAPSHOT
ToolBnd-3.5.0.201709291849
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-16077) camel-undertow - not respect content-type specified by REST DSL produces when body returns null
[
https://issues.apache.org/jira/browse/CAMEL-16077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-16077.
Fix Version/s: 3.8.0
Resolution: Fixed
> camel-undertow - not respect content-type specified by REST DSL produces when
> body returns null
> ---
>
> Key: CAMEL-16077
> URL: https://issues.apache.org/jira/browse/CAMEL-16077
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 3.7.1
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.8.0
>
>
> camel-undertow ignores content-type specified by REST DSL produces
> ({{"application/json"}}) and always returns {{"text/plain"}} when the
> exchange body returned from the REST endpoint is {{null}}:
> {code:xml}
> http://camel.apache.org/schema/spring;>
> contextPath="test" host="localhost" port="8005"/>
>
>
> direct:hello
>
>
>
>
>
>
>
>
> ${null}
>
>
>
>
> {code}
> This behaviour doesn't align with camel-jetty & REST DSL or bare undertow
> server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16077) camel-undertow - not respect content-type specified by REST DSL produces when body returns null
Tadayoshi Sato created CAMEL-16077:
--
Summary: camel-undertow - not respect content-type specified by
REST DSL produces when body returns null
Key: CAMEL-16077
URL: https://issues.apache.org/jira/browse/CAMEL-16077
Project: Camel
Issue Type: Bug
Components: camel-undertow
Affects Versions: 3.7.1
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
camel-undertow ignores content-type specified by REST DSL produces
({{"application/json"}}) and always returns {{"text/plain"}} when the exchange
body returned from the REST endpoint is {{null}}:
{code:xml}
http://camel.apache.org/schema/spring;>
direct:hello
${null}
{code}
This behaviour doesn't align with camel-jetty & REST DSL or bare undertow
server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-16019) Create another Camel Paho component for MQTT 5 support
[ https://issues.apache.org/jira/browse/CAMEL-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-16019 started by Tadayoshi Sato. -- > Create another Camel Paho component for MQTT 5 support > -- > > Key: CAMEL-16019 > URL: https://issues.apache.org/jira/browse/CAMEL-16019 > Project: Camel > Issue Type: New Feature > Components: camel-paho >Affects Versions: 3.7.0 >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Major > > Current camel-paho uses MQTT v3 client library. We need a camel-paho version > that uses [MQTT v5 client > library|https://github.com/eclipse/paho.mqtt.java/tree/v1.2.5/org.eclipse.paho.mqttv5.client] > so that we can use MQTT 5 with Camel. > About the component name: which one do we prefer? > - camel-paho5 > - camel-paho-mqtt5 > - anything else -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16019) Create another Camel Paho component for MQTT 5 support
[
https://issues.apache.org/jira/browse/CAMEL-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263145#comment-17263145
]
Tadayoshi Sato commented on CAMEL-16019:
[~davsclaus] I thought so initially but unlike MQTT 3.1 and 3.1.1 Paho provides
different package namespaces for v3 and v5 with the conflicting classnames such
as {{MqttClient}}, {{MqttMessage}}, etc., and the connection options are not
exactly identical between the versions.
https://github.com/eclipse/paho.mqtt.java#using-the-paho-java-client
We could overload the two client versions in a single camel-paho by switching
{{MqttClient}} versions internally, but I'm not sure if it can be a clean
implementation. Do you still think we should keep it a single component?
> Create another Camel Paho component for MQTT 5 support
> --
>
> Key: CAMEL-16019
> URL: https://issues.apache.org/jira/browse/CAMEL-16019
> Project: Camel
> Issue Type: New Feature
> Components: camel-paho
>Affects Versions: 3.7.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> Current camel-paho uses MQTT v3 client library. We need a camel-paho version
> that uses [MQTT v5 client
> library|https://github.com/eclipse/paho.mqtt.java/tree/v1.2.5/org.eclipse.paho.mqttv5.client]
> so that we can use MQTT 5 with Camel.
> About the component name: which one do we prefer?
> - camel-paho5
> - camel-paho-mqtt5
> - anything else
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-16019) Create another Camel Paho component for MQTT 5 support
[ https://issues.apache.org/jira/browse/CAMEL-16019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-16019: --- Issue Type: New Feature (was: Bug) > Create another Camel Paho component for MQTT 5 support > -- > > Key: CAMEL-16019 > URL: https://issues.apache.org/jira/browse/CAMEL-16019 > Project: Camel > Issue Type: New Feature > Components: camel-paho >Affects Versions: 3.7.0 >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Major > > Current camel-paho uses MQTT v3 client library. We need a camel-paho version > that uses [MQTT v5 client > library|https://github.com/eclipse/paho.mqtt.java/tree/v1.2.5/org.eclipse.paho.mqttv5.client] > so that we can use MQTT 5 with Camel. > About the component name: which one do we prefer? > - camel-paho5 > - camel-paho-mqtt5 > - anything else -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16019) Create another Camel Paho component for MQTT 5 support
Tadayoshi Sato created CAMEL-16019: -- Summary: Create another Camel Paho component for MQTT 5 support Key: CAMEL-16019 URL: https://issues.apache.org/jira/browse/CAMEL-16019 Project: Camel Issue Type: Bug Components: camel-paho Affects Versions: 3.7.0 Reporter: Tadayoshi Sato Assignee: Tadayoshi Sato Current camel-paho uses MQTT v3 client library. We need a camel-paho version that uses [MQTT v5 client library|https://github.com/eclipse/paho.mqtt.java/tree/v1.2.5/org.eclipse.paho.mqttv5.client] so that we can use MQTT 5 with Camel. About the component name: which one do we prefer? - camel-paho5 - camel-paho-mqtt5 - anything else -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14956) Create a websocket component based on Vertx
[ https://issues.apache.org/jira/browse/CAMEL-14956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-14956: --- Summary: Create a websocket component based on Vertx (was: Creaate a websocket component based on Vertx) > Create a websocket component based on Vertx > --- > > Key: CAMEL-14956 > URL: https://issues.apache.org/jira/browse/CAMEL-14956 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.x > > > We should have a Vertx based websocket component > https://vertx.io/docs/vertx-core/java/#_websockets > Maybe we can have a vertx component with a number of schemes/endpoints: > - vertx-ws > - vertx-http > - etc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14459) camel-webhook - RAW() parameter value handling in delegated URI
[
https://issues.apache.org/jira/browse/CAMEL-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030481#comment-17030481
]
Tadayoshi Sato commented on CAMEL-14459:
Worse, for camel-webhook {{RAW()}} wrapper seems to be stripped and thus
ignored at all. I'll take care of it here.
> camel-webhook - RAW() parameter value handling in delegated URI
> ---
>
> Key: CAMEL-14459
> URL: https://issues.apache.org/jira/browse/CAMEL-14459
> Project: Camel
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> It's possible that camel-webhook has the same issue as CAMEL-14456 with
> camel-master on handling {{RAW()}} parameter in the delegated URI. Let's
> check if it really has the issue or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-14459) camel-webhook - RAW() parameter value handling in delegated URI
[
https://issues.apache.org/jira/browse/CAMEL-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-14459 started by Tadayoshi Sato.
--
> camel-webhook - RAW() parameter value handling in delegated URI
> ---
>
> Key: CAMEL-14459
> URL: https://issues.apache.org/jira/browse/CAMEL-14459
> Project: Camel
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> It's possible that camel-webhook has the same issue as CAMEL-14456 with
> camel-master on handling {{RAW()}} parameter in the delegated URI. Let's
> check if it really has the issue or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14459) camel-webhook - RAW() parameter value handling in delegated URI
Tadayoshi Sato created CAMEL-14459:
--
Summary: camel-webhook - RAW() parameter value handling in
delegated URI
Key: CAMEL-14459
URL: https://issues.apache.org/jira/browse/CAMEL-14459
Project: Camel
Issue Type: Task
Affects Versions: 3.0.0
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
It's possible that camel-webhook has the same issue as CAMEL-14456 with
camel-master on handling {{RAW()}} parameter in the delegated URI. Let's check
if it really has the issue or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14456) camel-master - RAW() parameter value in delegated URI gets encoded
[
https://issues.apache.org/jira/browse/CAMEL-14456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-14456.
Resolution: Fixed
> camel-master - RAW() parameter value in delegated URI gets encoded
> --
>
> Key: CAMEL-14456
> URL: https://issues.apache.org/jira/browse/CAMEL-14456
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.25.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Given the following endpoint URI:
> {code}
> master:test:dummy://path?foo=hello}+world=RAW(hello}+world)
> {code}
> the value of parameter {{bar}} gets {{hello%7D+world}} instead of
> {{hello\}+world}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14456) camel-master - RAW() parameter value in delegated URI gets encoded
Tadayoshi Sato created CAMEL-14456:
--
Summary: camel-master - RAW() parameter value in delegated URI
gets encoded
Key: CAMEL-14456
URL: https://issues.apache.org/jira/browse/CAMEL-14456
Project: Camel
Issue Type: Bug
Affects Versions: 2.25.0, 3.0.0
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
Fix For: 3.1.0
Given the following endpoint URI:
{code}
master:test:dummy://path?foo=hello}+world=RAW(hello}+world)
{code}
the value of parameter {{bar}} gets {{hello%7D+world}} instead of
{{hello\}+world}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14207) camel-olingo2 - Basic auth with endpointHttpHeaders not working
[ https://issues.apache.org/jira/browse/CAMEL-14207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato resolved CAMEL-14207. Resolution: Fixed > camel-olingo2 - Basic auth with endpointHttpHeaders not working > > > Key: CAMEL-14207 > URL: https://issues.apache.org/jira/browse/CAMEL-14207 > Project: Camel > Issue Type: Bug > Components: camel-olingo2 >Affects Versions: 3.0.0.RC3 >Reporter: Tadayoshi Sato >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 3.0.0 > > > This bug is the Olingo2 version of CAMEL-13464. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14207) camel-olingo2 - Basic auth with endpointHttpHeaders not working
Tadayoshi Sato created CAMEL-14207: -- Summary: camel-olingo2 - Basic auth with endpointHttpHeaders not working Key: CAMEL-14207 URL: https://issues.apache.org/jira/browse/CAMEL-14207 Project: Camel Issue Type: Bug Components: camel-olingo2 Affects Versions: 3.0.0.RC3 Reporter: Tadayoshi Sato Assignee: Tadayoshi Sato Fix For: 3.0.0 This bug is the Olingo2 version of CAMEL-13464. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
[
https://issues.apache.org/jira/browse/CAMEL-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16978065#comment-16978065
]
Tadayoshi Sato commented on CAMEL-14178:
With this fix, only message annotations are supported. To support reading
delivery annotations QPIDJMS-153 needs to be implemented.
> camel-amqp - Add support for reading AMQP anntations
>
>
> Key: CAMEL-14178
> URL: https://issues.apache.org/jira/browse/CAMEL-14178
> Project: Camel
> Issue Type: New Feature
> Components: camel-amqp
>Affects Versions: 3.0.0.RC3
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0.RC4
>
>
> The old [Qpid JMS AMPQ
> 0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
> reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
> camel-amqp, which is based on the newer Qpid JMS client, lacks the same
> ability -- QPIDJMS-153. But users may want to read those annotations from an
> AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
[
https://issues.apache.org/jira/browse/CAMEL-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-14178.
Resolution: Fixed
> camel-amqp - Add support for reading AMQP anntations
>
>
> Key: CAMEL-14178
> URL: https://issues.apache.org/jira/browse/CAMEL-14178
> Project: Camel
> Issue Type: New Feature
> Components: camel-amqp
>Affects Versions: 3.0.0.RC3
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0.RC4
>
>
> The old [Qpid JMS AMPQ
> 0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
> reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
> camel-amqp, which is based on the newer Qpid JMS client, lacks the same
> ability -- QPIDJMS-153. But users may want to read those annotations from an
> AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
[
https://issues.apache.org/jira/browse/CAMEL-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-14178:
---
Fix Version/s: 3.0.0.RC4
> camel-amqp - Add support for reading AMQP anntations
>
>
> Key: CAMEL-14178
> URL: https://issues.apache.org/jira/browse/CAMEL-14178
> Project: Camel
> Issue Type: New Feature
> Components: camel-amqp
>Affects Versions: 3.0.0.RC3
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0.RC4
>
>
> The old [Qpid JMS AMPQ
> 0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
> reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
> camel-amqp, which is based on the newer Qpid JMS client, lacks the same
> ability -- QPIDJMS-153. But users may want to read those annotations from an
> AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
[
https://issues.apache.org/jira/browse/CAMEL-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-14178 started by Tadayoshi Sato.
--
> camel-amqp - Add support for reading AMQP anntations
>
>
> Key: CAMEL-14178
> URL: https://issues.apache.org/jira/browse/CAMEL-14178
> Project: Camel
> Issue Type: New Feature
> Components: camel-amqp
>Affects Versions: 3.0.0.RC3
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> The old [Qpid JMS AMPQ
> 0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
> reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
> camel-amqp, which is based on the newer Qpid JMS client, lacks the same
> ability -- QPIDJMS-153. But users may want to read those annotations from an
> AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
[
https://issues.apache.org/jira/browse/CAMEL-14178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-14178:
---
Description: The old [Qpid JMS AMPQ
0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
camel-amqp, which is based on the newer Qpid JMS client, lacks the same ability
-- QPIDJMS-153. But users may want to read those annotations from an AMQP
message. (was: The old [Qpid JMS AMPQ
0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
camel-amqp, which is based on the newer Qpid JMS client, lacks the same ability
QPIDJMS-153. But users may want to read those annotations from an AMQP message.)
> camel-amqp - Add support for reading AMQP anntations
>
>
> Key: CAMEL-14178
> URL: https://issues.apache.org/jira/browse/CAMEL-14178
> Project: Camel
> Issue Type: New Feature
> Components: camel-amqp
>Affects Versions: 3.0.0.RC3
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> The old [Qpid JMS AMPQ
> 0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
> reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
> camel-amqp, which is based on the newer Qpid JMS client, lacks the same
> ability -- QPIDJMS-153. But users may want to read those annotations from an
> AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14178) camel-amqp - Add support for reading AMQP anntations
Tadayoshi Sato created CAMEL-14178:
--
Summary: camel-amqp - Add support for reading AMQP anntations
Key: CAMEL-14178
URL: https://issues.apache.org/jira/browse/CAMEL-14178
Project: Camel
Issue Type: New Feature
Components: camel-amqp
Affects Versions: 3.0.0.RC3
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
The old [Qpid JMS AMPQ
0.x|https://qpid.apache.org/components/jms/amqp-0-x.html] had support for
reading AMQP annotations under {{JMS_AMQP_*}} properties but the current
camel-amqp, which is based on the newer Qpid JMS client, lacks the same ability
QPIDJMS-153. But users may want to read those annotations from an AMQP message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14020) Migrate deprecate getOut to getMessage in tests
[ https://issues.apache.org/jira/browse/CAMEL-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940662#comment-16940662 ] Tadayoshi Sato commented on CAMEL-14020: So, probably migrating getOut to getMessage on components should come first before working on this? > Migrate deprecate getOut to getMessage in tests > --- > > Key: CAMEL-14020 > URL: https://issues.apache.org/jira/browse/CAMEL-14020 > Project: Camel > Issue Type: Task > Components: tests > Environment: When you compile a component then deprecated WARNs is > logged by the compiler. The getOut on Message should be using getMessage in > the tests. >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14020) Migrate deprecate getOut to getMessage in tests
[
https://issues.apache.org/jira/browse/CAMEL-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16940659#comment-16940659
]
Tadayoshi Sato commented on CAMEL-14020:
I'm concerned that some tests elaborately use {{getOut()}} in order to simulate
the actual component behaviours and thus changing {{getOut()}} to
{{getMessage()}} may change the meanings of the tests and make them worthless.
Example:
https://github.com/apache/camel/blob/master/platforms/spring-boot/components-starter/camel-servlet-starter/src/test/java/org/apache/camel/component/servlet/springboot/test/ServletHttpMessageTest.java#L61
The problem here is that tests may still pass but since the meanings are
changed they may no longer do meaningful tests.
> Migrate deprecate getOut to getMessage in tests
> ---
>
> Key: CAMEL-14020
> URL: https://issues.apache.org/jira/browse/CAMEL-14020
> Project: Camel
> Issue Type: Task
> Components: tests
> Environment: When you compile a component then deprecated WARNs is
> logged by the compiler. The getOut on Message should be using getMessage in
> the tests.
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.x
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Fix Version/s: 2.25.0
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
> The real root cause is that when an exchange has an {{HttpMessage}} with
> {{null}} body as its out message, then the next time
> {{Exchange.getMessage()}} is invoked the {{HttpMessage}} is tricked by the
> {{null}} body and tries to create body again with the already closed request
> input stream.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-13886.
Resolution: Fixed
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0.RC2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
> The real root cause is that when an exchange has an {{HttpMessage}} with
> {{null}} body as its out message, then the next time
> {{Exchange.getMessage()}} is invoked the {{HttpMessage}} is tricked by the
> {{null}} body and tries to create body again with the already closed request
> input stream.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Fix Version/s: 3.0.0.RC2
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0.RC2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
> The real root cause is that when an exchange has an {{HttpMessage}} with
> {{null}} body as its out message, then the next time
> {{Exchange.getMessage()}} is invoked the {{HttpMessage}} is tricked by the
> {{null}} body and tries to create body again with the already closed request
> input stream.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CAMEL-13788) camel3 - Message API - Deprecate OUT
[
https://issues.apache.org/jira/browse/CAMEL-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913910#comment-16913910
]
Tadayoshi Sato commented on CAMEL-13788:
[~davsclaus] I see {{Exchange.getOut()}} is marked {{@deprecated}}, which is
fine for me. But some (or many?) components still seem to require putting its
returns to out message, so invoking {{Exchange.getOut()}} seems to be
necessary. What is then the expected way for components to put its returns to
an exchange? Is overwriting the in message directly the way to go?
> camel3 - Message API - Deprecate OUT
>
>
> Key: CAMEL-13788
> URL: https://issues.apache.org/jira/browse/CAMEL-13788
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.0.0, 3.0.0.RC1
>
>
> http://mail-archives.apache.org/mod_mbox/camel-dev/201907.mbox/%3CCAGB5yNkyx9LYk40UwGQdq_%2BiZH%3DOrqOifnqp%2BNL7vmv2TSJvnw%40mail.gmail.com%3E
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Description:
A Rest DSL route like the following causes {{java.io.IOException: Stream
closed}} when invoked at http://localhost:8000/test/proxy:
{code:java}
rest("/test")
.get("/proxy")
.to("direct:callInternalRestService");
from("direct:callInternalRestService")
.setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
//.setBody(constant("")) // workaround for null body and http4
component
.to("http4://localhost:9000/test?bridgeEndpoint=true")
.log("${body}");
{code}
The error stacktrace:
{code}
Caused by: java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
at
org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
at
org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
at
org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
... 54 common frames omitted
{code}
-This seems to happen only when Tomcat is used as the container with Spring
Boot. Undertow doesn't cause such an issue.-
The real root cause is that when an exchange has an {{HttpMessage}} with
{{null}} body as its out message, then the next time {{Exchange.getMessage()}}
is invoked the {{HttpMessage}} is tricked by the {{null}} body and tries to
create body again with the already closed request input stream.
was:
A Rest DSL route like the following causes {{java.io.IOException: Stream
closed}} when invoked at http://localhost:8000/test/proxy:
{code:java}
rest("/test")
.get("/proxy")
.to("direct:callInternalRestService");
from("direct:callInternalRestService")
.setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
//.setBody(constant("")) // workaround for null body and http4
component
.to("http4://localhost:9000/test?bridgeEndpoint=true")
.log("${body}");
{code}
The error stacktrace:
{code}
Caused by: java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
at
org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
at
org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
at
org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
... 54 common frames omitted
{code}
-This seems to happen only when Tomcat is used as the container with Spring
Boot. Undertow doesn't cause such an issue.-
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
>
[jira] [Work started] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-13886 started by Tadayoshi Sato.
--
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913906#comment-16913906
]
Tadayoshi Sato commented on CAMEL-13886:
[~davsclaus] No, it turned out my previous fix was not really correct. I
reverted it from both 2.x and 3.x. I'm working on a better fix right now.
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Fix Version/s: (was: 3.0.0.RC1)
(was: 2.25.0)
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> -This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.-
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CAMEL-13788) camel3 - Message API - Deprecate OUT
[ https://issues.apache.org/jira/browse/CAMEL-13788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-13788: --- Description: http://mail-archives.apache.org/mod_mbox/camel-dev/201907.mbox/%3CCAGB5yNkyx9LYk40UwGQdq_%2BiZH%3DOrqOifnqp%2BNL7vmv2TSJvnw%40mail.gmail.com%3E > camel3 - Message API - Deprecate OUT > > > Key: CAMEL-13788 > URL: https://issues.apache.org/jira/browse/CAMEL-13788 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0, 3.0.0.RC1 > > > http://mail-archives.apache.org/mod_mbox/camel-dev/201907.mbox/%3CCAGB5yNkyx9LYk40UwGQdq_%2BiZH%3DOrqOifnqp%2BNL7vmv2TSJvnw%40mail.gmail.com%3E -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Description:
A Rest DSL route like the following causes {{java.io.IOException: Stream
closed}} when invoked at http://localhost:8000/test/proxy:
{code:java}
rest("/test")
.get("/proxy")
.to("direct:callInternalRestService");
from("direct:callInternalRestService")
.setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
//.setBody(constant("")) // workaround for null body and http4
component
.to("http4://localhost:9000/test?bridgeEndpoint=true")
.log("${body}");
{code}
The error stacktrace:
{code}
Caused by: java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
at
org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
at
org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
at
org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
... 54 common frames omitted
{code}
-This seems to happen only when Tomcat is used as the container with Spring
Boot. Undertow doesn't cause such an issue.-
was:
A Rest DSL route like the following causes {{java.io.IOException: Stream
closed}} when invoked at http://localhost:8000/test/proxy:
{code:java}
rest("/test")
.get("/proxy")
.to("direct:callInternalRestService");
from("direct:callInternalRestService")
.setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
//.setBody(constant("")) // workaround for null body and http4
component
.to("http4://localhost:9000/test?bridgeEndpoint=true")
.log("${body}");
{code}
The error stacktrace:
{code}
Caused by: java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
at
org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
at
org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
at
org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
... 54 common frames omitted
{code}
This seems to happen only when Tomcat is used as the container with Spring
Boot. Undertow doesn't cause such an issue.
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC1
>
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
>
[jira] [Reopened] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato reopened CAMEL-13886:
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC1
>
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912859#comment-16912859
]
Tadayoshi Sato commented on CAMEL-13886:
[~coheigea] Yes, I noticed the failures too. Working on it. Thanks for your
notification.
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC1
>
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13886:
---
Fix Version/s: 3.0.0.RC1
2.25.0
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC1
>
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
[
https://issues.apache.org/jira/browse/CAMEL-13886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-13886.
Resolution: Fixed
> camel-servlet + camel-http4 with null body causes "Stream closed" IOException
> -
>
> Key: CAMEL-13886
> URL: https://issues.apache.org/jira/browse/CAMEL-13886
> Project: Camel
> Issue Type: Bug
> Components: camel-http-common, camel-http4, camel-servlet
>Affects Versions: 2.25.0, 3.0.0.M4
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.25.0, 3.0.0.RC1
>
>
> A Rest DSL route like the following causes {{java.io.IOException: Stream
> closed}} when invoked at http://localhost:8000/test/proxy:
> {code:java}
> rest("/test")
> .get("/proxy")
> .to("direct:callInternalRestService");
> from("direct:callInternalRestService")
> .setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
> //.setBody(constant("")) // workaround for null body and
> http4 component
> .to("http4://localhost:9000/test?bridgeEndpoint=true")
> .log("${body}");
> {code}
> The error stacktrace:
> {code}
> Caused by: java.io.IOException: Stream closed
> at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
> at
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
> at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
> at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
> at
> org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
> at
> org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
> at
> org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
> ... 54 common frames omitted
> {code}
> This seems to happen only when Tomcat is used as the container with Spring
> Boot. Undertow doesn't cause such an issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CAMEL-13886) camel-servlet + camel-http4 with null body causes "Stream closed" IOException
Tadayoshi Sato created CAMEL-13886:
--
Summary: camel-servlet + camel-http4 with null body causes "Stream
closed" IOException
Key: CAMEL-13886
URL: https://issues.apache.org/jira/browse/CAMEL-13886
Project: Camel
Issue Type: Bug
Components: camel-http-common, camel-http4, camel-servlet
Affects Versions: 3.0.0.M4, 2.25.0
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
A Rest DSL route like the following causes {{java.io.IOException: Stream
closed}} when invoked at http://localhost:8000/test/proxy:
{code:java}
rest("/test")
.get("/proxy")
.to("direct:callInternalRestService");
from("direct:callInternalRestService")
.setHeader(Exchange.HTTP_METHOD, constant("DELETE"))
//.setBody(constant("")) // workaround for null body and http4
component
.to("http4://localhost:9000/test?bridgeEndpoint=true")
.log("${body}");
{code}
The error stacktrace:
{code}
Caused by: java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:372)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:156)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:202)
at org.apache.camel.util.IOHelper.copy(IOHelper.java:174)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:234)
at org.apache.camel.util.IOHelper.copyAndCloseInput(IOHelper.java:230)
at
org.apache.camel.http.common.HttpHelper.readResponseBodyFromInputStream(HttpHelper.java:245)
at
org.apache.camel.http.common.HttpHelper.readRequestBodyFromServletRequest(HttpHelper.java:196)
at
org.apache.camel.http.common.DefaultHttpBinding.parseBody(DefaultHttpBinding.java:577)
at
org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:78)
... 54 common frames omitted
{code}
This seems to happen only when Tomcat is used as the container with Spring
Boot. Undertow doesn't cause such an issue.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CAMEL-13622) Website - Add filter box at the top of left menu in component reference
[ https://issues.apache.org/jira/browse/CAMEL-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910945#comment-16910945 ] Tadayoshi Sato commented on CAMEL-13622: [~zregvart] Awesome, thanks! > Website - Add filter box at the top of left menu in component reference > --- > > Key: CAMEL-13622 > URL: https://issues.apache.org/jira/browse/CAMEL-13622 > Project: Camel > Issue Type: Sub-task > Components: website >Reporter: Tadayoshi Sato >Assignee: Zoran Regvart >Priority: Major > Attachments: component-reference-left-menu.png > > > If possible, add filtering box that filter components by name in the left > menu of Component Reference page: > [https://camel.apache.org/staging/components/latest/] > I think this page is the most referenced page by users and such a filtering > box improves the usability of this page a lot. > !component-reference-left-menu.png! -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (CAMEL-11497) Migrate the rest of the Confluence content
[ https://issues.apache.org/jira/browse/CAMEL-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890948#comment-16890948 ] Tadayoshi Sato commented on CAMEL-11497: If my memory serves me well there are still quite a few architecture docs left in confluence wiki. Other than that, +1 to Zoran's proposal and close it. > Migrate the rest of the Confluence content > -- > > Key: CAMEL-11497 > URL: https://issues.apache.org/jira/browse/CAMEL-11497 > Project: Camel > Issue Type: Sub-task > Components: website >Reporter: Zoran Regvart >Assignee: Zoran Regvart >Priority: Major > Fix For: Future > > Time Spent: 20m > Remaining Estimate: 0h > > There are still pages in the Confluence that are not migrated to Asciidoctor -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (CAMEL-13734) camel-undertow - Support streaming of large data for HTTP endpoints
Tadayoshi Sato created CAMEL-13734:
--
Summary: camel-undertow - Support streaming of large data for HTTP
endpoints
Key: CAMEL-13734
URL: https://issues.apache.org/jira/browse/CAMEL-13734
Project: Camel
Issue Type: New Feature
Components: camel-undertow
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
Currently messages with body of large data {{InputStream}} are always converted
to {{byte[]}} on a Camel route for both producer and consumer HTTP endpoints,
thus cause {{OutOfMemoryError}} and fail in the middle of processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13623) Website - Multiproject components not listed in Component Reference
Tadayoshi Sato created CAMEL-13623:
--
Summary: Website - Multiproject components not listed in Component
Reference
Key: CAMEL-13623
URL: https://issues.apache.org/jira/browse/CAMEL-13623
Project: Camel
Issue Type: Bug
Components: website
Reporter: Tadayoshi Sato
Components that have the structure of:
{code}
camel-box/
├── camel-box-api/
└── camel-box-component/
{code}
are not listed in the left menu of Component Reference:
https://camel.apache.org/staging/components/latest/
This includes camel-as2, camel-box, camel-fhir, camel-linkedin, and
camel-olingoX.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13622) Website - Add filter box at the top of left menu in component reference
Tadayoshi Sato created CAMEL-13622: -- Summary: Website - Add filter box at the top of left menu in component reference Key: CAMEL-13622 URL: https://issues.apache.org/jira/browse/CAMEL-13622 Project: Camel Issue Type: Improvement Components: website Reporter: Tadayoshi Sato Attachments: component-reference-left-menu.png If possible, add filtering box that filter components by name in the left menu of Component Reference page: [https://camel.apache.org/staging/components/latest/] I think this page is the most referenced page by users and such a filtering box improves the usability of this page a lot. !component-reference-left-menu.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13136) File consumer with charset doesn't parse XML
[
https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16839236#comment-16839236
]
Tadayoshi Sato commented on CAMEL-13136:
Thanks [~davsclaus]. Yes, you are right. We can directly refer to {{IOHelper}}
from {{GenericFileConverter}}. I'm making a pull req that applies the needed
changes.
> File consumer with charset doesn't parse XML
>
>
> Key: CAMEL-13136
> URL: https://issues.apache.org/jira/browse/CAMEL-13136
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0-M1
>Reporter: Thomas Diesler
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0
>
>
> This now shows on camel-3.0
> https://issues.jboss.org/browse/ENTESB-10033
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-13136) File consumer with charset doesn't parse XML
[
https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835499#comment-16835499
]
Tadayoshi Sato edited comment on CAMEL-13136 at 5/8/19 10:35 AM:
-
[~davsclaus] It appears that this regression has been introduced along with
CAMEL-13112, where
[EncodingInputStream|https://github.com/apache/camel/blob/camel-3.0.0-M2/components/camel-file/src/main/java/org/apache/camel/component/file/GenericFileConverter.java#L259-L301]
has been cloned into {{GenericFileConverter}} and thus [this
condition|https://github.com/apache/camel/blob/camel-3.0.0-M2/core/camel-base/src/main/java/org/apache/camel/converter/jaxp/XmlConverter.java#L695]
never becomes true in {{XmlConverter}}. I understand that {{camel-file}} can
only depend on {{camel-support}}, so what do you think would be the best way to
fix it?
Can we make {{camel-file}} depend also on {{camel-util}}? Or should we instead
move {{EncodingInputStream}} out of {{IOHelper}} in {{camel-util}} and into
{{camel-support}}?
was (Author: tadayosi):
[~davsclaus] It appears that this regression has been introduced along with
CAMEL-13112, where
[EncodingInputStream|https://github.com/apache/camel/blob/camel-3.0.0-M2/components/camel-file/src/main/java/org/apache/camel/component/file/GenericFileConverter.java#L259-L301]
has been cloned into {{GenericFileConverter}} and thus [this
condition|https://github.com/apache/camel/blob/camel-3.0.0-M2/core/camel-base/src/main/java/org/apache/camel/converter/jaxp/XmlConverter.java#L695]
never becomes true in {{XmlConverter}}. I understand that {{camel-file}} can
only depend on {{camel-support}}, so what do you think would be the best way to
fix it?
> File consumer with charset doesn't parse XML
>
>
> Key: CAMEL-13136
> URL: https://issues.apache.org/jira/browse/CAMEL-13136
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0-M1
>Reporter: Thomas Diesler
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0
>
>
> This now shows on camel-3.0
> https://issues.jboss.org/browse/ENTESB-10033
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13136) File consumer with charset doesn't parse XML
[
https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835499#comment-16835499
]
Tadayoshi Sato commented on CAMEL-13136:
[~davsclaus] It appears that this regression has been introduced along with
CAMEL-13112, where
[EncodingInputStream|https://github.com/apache/camel/blob/camel-3.0.0-M2/components/camel-file/src/main/java/org/apache/camel/component/file/GenericFileConverter.java#L259-L301]
has been cloned into {{GenericFileConverter}} and thus [this
condition|https://github.com/apache/camel/blob/camel-3.0.0-M2/core/camel-base/src/main/java/org/apache/camel/converter/jaxp/XmlConverter.java#L695]
never becomes true in {{XmlConverter}}. I understand that {{camel-file}} can
only depend on {{camel-support}}, so what do you think would be the best way to
fix it?
> File consumer with charset doesn't parse XML
>
>
> Key: CAMEL-13136
> URL: https://issues.apache.org/jira/browse/CAMEL-13136
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.0.0-M1
>Reporter: Thomas Diesler
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0
>
>
> This now shows on camel-3.0
> https://issues.jboss.org/browse/ENTESB-10033
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13136) File consumer with charset doesn't parse XML
[ https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-13136: --- Affects Version/s: 3.0.0-M1 > File consumer with charset doesn't parse XML > > > Key: CAMEL-13136 > URL: https://issues.apache.org/jira/browse/CAMEL-13136 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.0.0-M1 >Reporter: Thomas Diesler >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 3.0.0 > > > This now shows on camel-3.0 > https://issues.jboss.org/browse/ENTESB-10033 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-13136) File consumer with charset doesn't parse XML
[ https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-13136 started by Tadayoshi Sato. -- > File consumer with charset doesn't parse XML > > > Key: CAMEL-13136 > URL: https://issues.apache.org/jira/browse/CAMEL-13136 > Project: Camel > Issue Type: Bug > Components: camel-core >Reporter: Thomas Diesler >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 3.0.0 > > > This now shows on camel-3.0 > https://issues.jboss.org/browse/ENTESB-10033 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13136) File consumer with charset doesn't parse XML
[ https://issues.apache.org/jira/browse/CAMEL-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato updated CAMEL-13136: --- Component/s: camel-core > File consumer with charset doesn't parse XML > > > Key: CAMEL-13136 > URL: https://issues.apache.org/jira/browse/CAMEL-13136 > Project: Camel > Issue Type: Bug > Components: camel-core >Reporter: Thomas Diesler >Assignee: Tadayoshi Sato >Priority: Major > Fix For: 3.0.0 > > > This now shows on camel-3.0 > https://issues.jboss.org/browse/ENTESB-10033 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-13376) camel-cxf - failure processor for custom exception handling cannot get the original message
[ https://issues.apache.org/jira/browse/CAMEL-13376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tadayoshi Sato reassigned CAMEL-13376: -- Assignee: Tadayoshi Sato > camel-cxf - failure processor for custom exception handling cannot get the > original message > --- > > Key: CAMEL-13376 > URL: https://issues.apache.org/jira/browse/CAMEL-13376 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.21.0 > Environment: Redhat Fuse 7.0 (on EAP) > reproduced with current "camel-example-cxf-proxy" example >Reporter: Jochen Riedlinger >Assignee: Tadayoshi Sato >Priority: Minor > > I configured custom exception handling for a CXF consumer where I want to use > my own processor. > > Lile this: > > onException(Exception.class) > .handled(false) > .useOriginalMessage() > .process(failureResponseProcessor); > > or: > > > java.lang.Exception > false > > > If allowStreaming is enabled on the CXF consumer endpoint, my > FailureResponseProcessor cannot get the original body (the body part of > CachedCxfPayload seems to be empty). > If I set allowStreaming to false, the processor works as expected. > I did a branch on my fork to create this reproducer: > https://github.com/jochenr/camel/tree/Reproducer-CXF-CustomExceptionHandling-in-StreamingMode/examples/camel-example-cxf-proxy > If you toggle the setting of allowStreaming between true and false, you see > the different output to the console, right after the string > "This was the original BODY that caused the fault:" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13428) camel-undertow - Response with large data gets truncated on cloud
[
https://issues.apache.org/jira/browse/CAMEL-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato updated CAMEL-13428:
---
Fix Version/s: 3.0.0
> camel-undertow - Response with large data gets truncated on cloud
> -
>
> Key: CAMEL-13428
> URL: https://issues.apache.org/jira/browse/CAMEL-13428
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 3.0.0-M2
> Environment: On Kubernetes / OpenShift
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0, 3.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a Spring Boot application with camel-undertow is deployed on a
> Kubernetes environment, say OpenShift, responses with large data may get
> truncated.
> {code}
> $ curl -sv hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com >
> out
> * Trying 52.36.115.21...
> * TCP_NODELAY set
> * Connected to
> hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> (52.36.115.21) port 80 (#0)
> > GET / HTTP/1.1
> > Host: hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Accept: */*
> < User-Agent: curl/7.64.1
> < Forwarded:
> for=27.95.227.48;host=hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com;proto=http;proto-version=
> < Date: Wed, 17 Apr 2019 11:18:54 GMT
> < X-Forwarded-Proto: http
> < X-Forwarded-Port: 80
> < X-Forwarded-For: 27.95.227.48
> < Content-Length: 100
> < X-Forwarded-Host:
> hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> < Set-Cookie:
> a87d1be1aa3f6decad88f44c63db4670=7939401110c788ff04e98b94cb1b682f; path=/;
> HttpOnly
> < Cache-control: private
> <
> { [921 bytes data]
> * transfer closed with 698964 bytes remaining to read
> * Closing connection 0
> {code}
> Notice the curl message: {{transfer closed with 698964 bytes remaining to
> read}}
> It depends on the throughput of the network and the size of response data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-13428) camel-undertow - Response with large data gets truncated on cloud
[
https://issues.apache.org/jira/browse/CAMEL-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tadayoshi Sato resolved CAMEL-13428.
Resolution: Fixed
Fix Version/s: 3.0.0-M3
> camel-undertow - Response with large data gets truncated on cloud
> -
>
> Key: CAMEL-13428
> URL: https://issues.apache.org/jira/browse/CAMEL-13428
> Project: Camel
> Issue Type: Bug
> Components: camel-undertow
>Affects Versions: 3.0.0-M2
> Environment: On Kubernetes / OpenShift
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 3.0.0-M3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When a Spring Boot application with camel-undertow is deployed on a
> Kubernetes environment, say OpenShift, responses with large data may get
> truncated.
> {code}
> $ curl -sv hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com >
> out
> * Trying 52.36.115.21...
> * TCP_NODELAY set
> * Connected to
> hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> (52.36.115.21) port 80 (#0)
> > GET / HTTP/1.1
> > Host: hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> > User-Agent: curl/7.64.1
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Accept: */*
> < User-Agent: curl/7.64.1
> < Forwarded:
> for=27.95.227.48;host=hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com;proto=http;proto-version=
> < Date: Wed, 17 Apr 2019 11:18:54 GMT
> < X-Forwarded-Proto: http
> < X-Forwarded-Port: 80
> < X-Forwarded-For: 27.95.227.48
> < Content-Length: 100
> < X-Forwarded-Host:
> hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> < Set-Cookie:
> a87d1be1aa3f6decad88f44c63db4670=7939401110c788ff04e98b94cb1b682f; path=/;
> HttpOnly
> < Cache-control: private
> <
> { [921 bytes data]
> * transfer closed with 698964 bytes remaining to read
> * Closing connection 0
> {code}
> Notice the curl message: {{transfer closed with 698964 bytes remaining to
> read}}
> It depends on the throughput of the network and the size of response data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13428) camel-undertow - Response with large data gets truncated on cloud
Tadayoshi Sato created CAMEL-13428:
--
Summary: camel-undertow - Response with large data gets truncated
on cloud
Key: CAMEL-13428
URL: https://issues.apache.org/jira/browse/CAMEL-13428
Project: Camel
Issue Type: Bug
Components: camel-undertow
Affects Versions: 3.0.0-M2
Environment: On Kubernetes / OpenShift
Reporter: Tadayoshi Sato
Assignee: Tadayoshi Sato
When a Spring Boot application with camel-undertow is deployed on a Kubernetes
environment, say OpenShift, responses with large data may get truncated.
{code}
$ curl -sv hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com >
out
* Trying 52.36.115.21...
* TCP_NODELAY set
* Connected to hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
(52.36.115.21) port 80 (#0)
> GET / HTTP/1.1
> Host: hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept: */*
< User-Agent: curl/7.64.1
< Forwarded:
for=27.95.227.48;host=hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com;proto=http;proto-version=
< Date: Wed, 17 Apr 2019 11:18:54 GMT
< X-Forwarded-Proto: http
< X-Forwarded-Port: 80
< X-Forwarded-For: 27.95.227.48
< Content-Length: 100
< X-Forwarded-Host:
hello-camel-tasato-test.7e14.starter-us-west-2.openshiftapps.com
< Set-Cookie:
a87d1be1aa3f6decad88f44c63db4670=7939401110c788ff04e98b94cb1b682f; path=/;
HttpOnly
< Cache-control: private
<
{ [921 bytes data]
* transfer closed with 698964 bytes remaining to read
* Closing connection 0
{code}
Notice the curl message: {{transfer closed with 698964 bytes remaining to read}}
It depends on the throughput of the network and the size of response data.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
