Re: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4

[Chirag]

@fyodor,


if you are familiar with camel-jbang

Try this:
Here is updated form
https://gist.github.com/chiragsanghavi/02a00f49ac7ee9a978344af571746c02

Yaml DSL:
https://gist.github.com/chiragsanghavi/8a2aee132fc626ed25f97fc0a360ead4

Try form 1 (to see the issue) and try form 2 to see it work as expected.


undertow created body as Map
jetty created body as
org.apache.camel.converter.stream.InputStreamCache resulting into
error.
No serializer found for class org.apache.camel.converter.stream.InputStreamCache


ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account

On Wed, Jun 14, 2023 at 5:32 PM Chirag  wrote:
>
> Can you try and run it with undertow? I see test similar to your
> scenario in undertow.
>
> https://github.com/apache/camel/tree/52443a298935b2842a402cb5fff7e37abb938f8b/components/camel-undertow/src/test/java/org/apache/camel/component/undertow
>
> ચિરાગ/चिराग/Chirag
> --
> Sent from My Gmail Account
>
> On Wed, Jun 14, 2023 at 4:37 PM Fyodor Kravchenko  
> wrote:
> >
> > The old-fashioned standard of the Servlet API required that the request
> > parameters were available through the request.getParameter* methods,
> > including the getParameterMap(), be that GET query parameters or the
> > POST form data load.
> >
> > Camel collects anything looking like a Map into the Camel
> > Message headers, mixing the HTTP request parameters, HTTP headers and
> > something else. It apparently continues to do so, however, somehow
> > clearing the HttpServletRequest.getParameter* results, but this isn't my
> > problem. It works the same way in Camel 2 and Camel 3.20.4 which I'm
> > trying to migrate to, and all inconsistencies are already worked around.
> >
> > My problem is that the Message.getBody(Map.class) behaviour has changed.
> > Try change Camel 3 to 2 in the pom.xml of the test project and the same
> > code will magically work as expected.
> >
> >
> > On 14.06.2023 19:25, Chirag wrote:
> > > if you introspect variables, the fields are not populated in
> > > HttpServletRequest object. The variables are added to the Camel
> > > Exchange Header. This may be something done within camel-jetty or one
> > > of the underlying libraries.
> > >
> > > the field are populated in the message header - but at that point,
> > > they are intermingled with Camel Headers, HTTP Headers
> > >
> > > Accept = 
> > > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
> > > Accept-Encoding = gzip, deflate, br
> > > Accept-Language = en-US,en;q=0.9
> > > Cache-Control = max-age=0
> > > CamelHttpMethod = POST
> > > CamelHttpPath =
> > > CamelHttpQuery = null
> > > CamelHttpServletRequest = Request(POST //localhost:8080/)@37bc1f86
> > > CamelHttpServletResponse = HTTP/1.1 200
> > >
> > >
> > > CamelHttpUri = /
> > > CamelHttpUrl = http://localhost:8080/
> > > CamelServletContextPath = /
> > > Connection = keep-alive
> > > Content-Length = 20
> > > Content-Type = application/x-www-form-urlencoded
> > > Host = localhost:8080
> > > login = aa
> > > Origin = http://localhost:8080
> > > password = bb
> > > Referer = http://localhost:8080/
> > > sec-ch-ua = "Not.A/Brand";v="8", "Chromium";v="114", "Microsoft 
> > > Edge";v="114"
> > > sec-ch-ua-mobile = ?0
> > > sec-ch-ua-platform = "Windows"
> > > Sec-Fetch-Dest = document
> > > Sec-Fetch-Mode = navigate
> > > Sec-Fetch-Site = same-origin
> > > Sec-Fetch-User = ?1
> > > Upgrade-Insecure-Requests = 1
> > > User-Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> > > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
> > > Edg/114.0.1823.43
> > >  End  of Message Headers
> > >
> > >
> > >
> > > I couldn't see an easy method to convert
> > > username=something&password=something (that can possibly be a
> > > workaround). I would say go ahead and open a JIRA ; to see if this is
> > > really a bug.
> > > I did see a slightly different behaviour when I added
> > > disableStreamCache=true; but that did not seem to change other parts.
> > > I did try changing it to a multi-part form and then it showed up as
> > > multiple parts attached - but that would mean changing your approach
> > > completely.
> > >
> > >
> > > ચિરાગ/चिराग/Chirag
> > > --
> > > Sent from My Gmail Account
> > > On Wed, Jun 14, 2023 at 3:14 AM Fyodor Kravchenko  
> > > wrote:
> > >> Hi Chirag, yeah that exactly is the question - it shouldn't be that way.
> > >>
> > >> If we change Camel version in the pom.xml to Camel 2.24, it'll work as
> > >> expected: the POST payload will be parsed into java.util.Map and the
> > >> Json will be generated (instead of "null").
> > >>
> > >> So the question is -- how do i fix it for camel 3.20.4?
> > >>
> > >> On 13.06.2023 18:04, Chirag wrote:
> > >>> Hi Fyodor,
> > >>> I ran it in IntelliJ thru 3.20.4
> > >>>
> > >>> after submitting page - i got
> > >>>
> > >>>

Re: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4

[Chirag]

Can you try and run it with undertow? I see test similar to your
scenario in undertow.

https://github.com/apache/camel/tree/52443a298935b2842a402cb5fff7e37abb938f8b/components/camel-undertow/src/test/java/org/apache/camel/component/undertow

ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account

On Wed, Jun 14, 2023 at 4:37 PM Fyodor Kravchenko  wrote:
>
> The old-fashioned standard of the Servlet API required that the request
> parameters were available through the request.getParameter* methods,
> including the getParameterMap(), be that GET query parameters or the
> POST form data load.
>
> Camel collects anything looking like a Map into the Camel
> Message headers, mixing the HTTP request parameters, HTTP headers and
> something else. It apparently continues to do so, however, somehow
> clearing the HttpServletRequest.getParameter* results, but this isn't my
> problem. It works the same way in Camel 2 and Camel 3.20.4 which I'm
> trying to migrate to, and all inconsistencies are already worked around.
>
> My problem is that the Message.getBody(Map.class) behaviour has changed.
> Try change Camel 3 to 2 in the pom.xml of the test project and the same
> code will magically work as expected.
>
>
> On 14.06.2023 19:25, Chirag wrote:
> > if you introspect variables, the fields are not populated in
> > HttpServletRequest object. The variables are added to the Camel
> > Exchange Header. This may be something done within camel-jetty or one
> > of the underlying libraries.
> >
> > the field are populated in the message header - but at that point,
> > they are intermingled with Camel Headers, HTTP Headers
> >
> > Accept = 
> > text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
> > Accept-Encoding = gzip, deflate, br
> > Accept-Language = en-US,en;q=0.9
> > Cache-Control = max-age=0
> > CamelHttpMethod = POST
> > CamelHttpPath =
> > CamelHttpQuery = null
> > CamelHttpServletRequest = Request(POST //localhost:8080/)@37bc1f86
> > CamelHttpServletResponse = HTTP/1.1 200
> >
> >
> > CamelHttpUri = /
> > CamelHttpUrl = http://localhost:8080/
> > CamelServletContextPath = /
> > Connection = keep-alive
> > Content-Length = 20
> > Content-Type = application/x-www-form-urlencoded
> > Host = localhost:8080
> > login = aa
> > Origin = http://localhost:8080
> > password = bb
> > Referer = http://localhost:8080/
> > sec-ch-ua = "Not.A/Brand";v="8", "Chromium";v="114", "Microsoft 
> > Edge";v="114"
> > sec-ch-ua-mobile = ?0
> > sec-ch-ua-platform = "Windows"
> > Sec-Fetch-Dest = document
> > Sec-Fetch-Mode = navigate
> > Sec-Fetch-Site = same-origin
> > Sec-Fetch-User = ?1
> > Upgrade-Insecure-Requests = 1
> > User-Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
> > Edg/114.0.1823.43
> >  End  of Message Headers
> >
> >
> >
> > I couldn't see an easy method to convert
> > username=something&password=something (that can possibly be a
> > workaround). I would say go ahead and open a JIRA ; to see if this is
> > really a bug.
> > I did see a slightly different behaviour when I added
> > disableStreamCache=true; but that did not seem to change other parts.
> > I did try changing it to a multi-part form and then it showed up as
> > multiple parts attached - but that would mean changing your approach
> > completely.
> >
> >
> > ચિરાગ/चिराग/Chirag
> > --
> > Sent from My Gmail Account
> > On Wed, Jun 14, 2023 at 3:14 AM Fyodor Kravchenko  
> > wrote:
> >> Hi Chirag, yeah that exactly is the question - it shouldn't be that way.
> >>
> >> If we change Camel version in the pom.xml to Camel 2.24, it'll work as
> >> expected: the POST payload will be parsed into java.util.Map and the
> >> Json will be generated (instead of "null").
> >>
> >> So the question is -- how do i fix it for camel 3.20.4?
> >>
> >> On 13.06.2023 18:04, Chirag wrote:
> >>> Hi Fyodor,
> >>> I ran it in IntelliJ thru 3.20.4
> >>>
> >>> after submitting page - i got
> >>>
> >>> json: null, and string:login=usrename&password=password
> >>>
> >>>
> >>> ચિરાગ/चिराग/Chirag
> >>> --
> >>> Sent from My Gmail Account
> >>>
> >>> On Mon, Jun 12, 2023 at 7:35 AM Fyodor Kravchenko  
> >>> wrote:
>  Hello people,
> 
>  any ideas how to fix the issue below?
> 
>  -- fedd
> 
>  On 09.06.2023 18:15, Fyodor Kravchenko wrote:
> > Hello,
> >
> > I've used to rely on this function in older Camel, when I was able to
> > deserialize a regular web form POST stream into a generic
> > java.util.Map, I mean, this used to parse the form data (not
> > multipart, just regular) and convert into a Map:
> >
> > Map map = http.getBody(Map.class);
> >
> > This is my test code snippet that I compile and run on Java 19 of
> > GraalVM:
> >
> > ```

Re: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4

[Fyodor Kravchenko]

The old-fashioned standard of the Servlet API required that the request 
parameters were available through the request.getParameter* methods, 
including the getParameterMap(), be that GET query parameters or the 
POST form data load.


Camel collects anything looking like a Map into the Camel 
Message headers, mixing the HTTP request parameters, HTTP headers and 
something else. It apparently continues to do so, however, somehow 
clearing the HttpServletRequest.getParameter* results, but this isn't my 
problem. It works the same way in Camel 2 and Camel 3.20.4 which I'm 
trying to migrate to, and all inconsistencies are already worked around.


My problem is that the Message.getBody(Map.class) behaviour has changed. 
Try change Camel 3 to 2 in the pom.xml of the test project and the same 
code will magically work as expected.



On 14.06.2023 19:25, Chirag wrote:

if you introspect variables, the fields are not populated in
HttpServletRequest object. The variables are added to the Camel
Exchange Header. This may be something done within camel-jetty or one
of the underlying libraries.

the field are populated in the message header - but at that point,
they are intermingled with Camel Headers, HTTP Headers

Accept = 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding = gzip, deflate, br
Accept-Language = en-US,en;q=0.9
Cache-Control = max-age=0
CamelHttpMethod = POST
CamelHttpPath =
CamelHttpQuery = null
CamelHttpServletRequest = Request(POST //localhost:8080/)@37bc1f86
CamelHttpServletResponse = HTTP/1.1 200


CamelHttpUri = /
CamelHttpUrl = http://localhost:8080/
CamelServletContextPath = /
Connection = keep-alive
Content-Length = 20
Content-Type = application/x-www-form-urlencoded
Host = localhost:8080
login = aa
Origin = http://localhost:8080
password = bb
Referer = http://localhost:8080/
sec-ch-ua = "Not.A/Brand";v="8", "Chromium";v="114", "Microsoft Edge";v="114"
sec-ch-ua-mobile = ?0
sec-ch-ua-platform = "Windows"
Sec-Fetch-Dest = document
Sec-Fetch-Mode = navigate
Sec-Fetch-Site = same-origin
Sec-Fetch-User = ?1
Upgrade-Insecure-Requests = 1
User-Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Edg/114.0.1823.43
 End  of Message Headers



I couldn't see an easy method to convert
username=something&password=something (that can possibly be a
workaround). I would say go ahead and open a JIRA ; to see if this is
really a bug.
I did see a slightly different behaviour when I added
disableStreamCache=true; but that did not seem to change other parts.
I did try changing it to a multi-part form and then it showed up as
multiple parts attached - but that would mean changing your approach
completely.


ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account
On Wed, Jun 14, 2023 at 3:14 AM Fyodor Kravchenko  wrote:

Hi Chirag, yeah that exactly is the question - it shouldn't be that way.

If we change Camel version in the pom.xml to Camel 2.24, it'll work as
expected: the POST payload will be parsed into java.util.Map and the
Json will be generated (instead of "null").

So the question is -- how do i fix it for camel 3.20.4?

On 13.06.2023 18:04, Chirag wrote:

Hi Fyodor,
I ran it in IntelliJ thru 3.20.4

after submitting page - i got

json: null, and string:login=usrename&password=password


ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account

On Mon, Jun 12, 2023 at 7:35 AM Fyodor Kravchenko  wrote:

Hello people,

any ideas how to fix the issue below?

-- fedd

On 09.06.2023 18:15, Fyodor Kravchenko wrote:

Hello,

I've used to rely on this function in older Camel, when I was able to
deserialize a regular web form POST stream into a generic
java.util.Map, I mean, this used to parse the form data (not
multipart, just regular) and convert into a Map:

Map map = http.getBody(Map.class);

This is my test code snippet that I compile and run on Java 19 of
GraalVM:

```

  HttpMessage http =
exchange.getIn(HttpMessage.class);
  HttpServletRequest request = http.getRequest();
  String method = request.getMethod();
  if ("POST".equals(method) ||
"PUT".equals(method)) {
  Map map = http.getBody(Map.class);
  String string = http.getBody(String.class);
  http.setHeader(Exchange.CONTENT_TYPE,
"text/plain");
  http.setBody("json: " +
mapper.writeValueAsString(map) + ", and string:" + string);
  } else {
  http.setHeader(Exchange.CONTENT_TYPE,
"text/html");
http.setBody(this.getClass().getResourceAsStream("form.html"));
  }
```

I've created a test project to make sure it works on Camel 2.24 and
doesn

AW: interceptSendToEndpoint broken when setting address of CxfEndpoint

[Speckels, Bert]

Thank you Claus.

I recently found out, why we didn't use the following code:

 CxfEndpoint endpoint = (CxfEndpoint) 
camelContext.getEndpoint("cxf://http://remotehost/ws/service";);

It happens that one of the soap service urls has query string like in the 
following example:

 CxfEndpoint endpoint = (CxfEndpoint) 
camelContext.getEndpoint("cxf://http://remotehost/ws/service?stage=INT&tenant=MyCompany";);

I think Camel does not support this because it also uses query parameters for 
configuration.

Is there any possiblity to encode the service url?

With kind recards
Bert Speckels



i.A. Bert Speckels
BU Software Factory
Smart Software Solutions



BTC Business Technology Consulting AG
Escherweg 3
26121 Oldenburg
Tel:  +49 441 3612-2294
Mobil:   +49 174 3436354
Fax: +49 441 3612-3999
E-Mail:  bert.speck...@btc-ag.com
Web: http://www.btc-ag.com/



Rechtliche Hinweise:
http://www.btc-ag.com/impressum.htm
Handelsregister: Amtsgericht Oldenburg HRB 4717
Aufsichtsratsvorsitzender: Wolfgang Mücher
Vorstand: Dr. Jörg Ritter (Vorstandsvorsitzender), Percy Hamer













Von: Claus Ibsen 
Gesendet: Dienstag, 13. Juni 2023 18:39
An: users@camel.apache.org 
Betreff: Re: interceptSendToEndpoint broken when setting address of CxfEndpoint

Hi

camel-cxf is a very old component. Yeah its not a good idea what it does,
and not sure if its really necessary.
You can try with git blame and see if you can find out some JIRA tickets or
some reason behind.

On Tue, Jun 13, 2023 at 12:08 PM Speckels, Bert 
wrote:

> Hello everyone.
>
> We have currently a problem with intercepting our cxf endpoint (sending):
>
> interceptSendToEndpoint("cxf*")
> .to("bean:mockSoapSendingInterceptor?method=mock");
>
> ---
>
> But I found the reason why intercepting does not work.
> We use java code to configure our CxfEndpoint:
>
> CxfEndpoint endpoint = (CxfEndpoint)
> camelContext.getEndpoint("cxf://OUR_ENDPOINT");
> endpoint.setAddress("http://remotehost/ws/service";);
> ...
>
> The problem is that setAddress(..) in CxfEndpoint not only set the target
> address but also replaces the endpoint uri.
> So the interceptor does not match because the endpoint uri doesn't start
> with "cxf" anymore but with "http".
>
> Here is the code from CXF:
>
> public void setAddress(String address) {
>
> super.setEndpointUri(UnsafeUriCharactersEncoder.encodeHttpURI(address));
> this.address = address;
> }
>
> Is this really a good idea to replace the endpoint uri starting with
> "cxf:" with the target url of the soap endpoint?
> ---
>
> We had some good reasons to use "setAdress" instead or passing the endpoit
> uri directly like in the following example:
>
> CxfEndpoint endpoint = (CxfEndpoint) camelContext.getEndpoint("cxf://
> http://remotehost/ws/service";);
>
> I will try to figure out why this was not possible for us.
> But in the meantime: Maybe you have some other hints for me?!
>
> With kind regards
> Bert Speckels



--
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4

[Chirag]

if you introspect variables, the fields are not populated in
HttpServletRequest object. The variables are added to the Camel
Exchange Header. This may be something done within camel-jetty or one
of the underlying libraries.

the field are populated in the message header - but at that point,
they are intermingled with Camel Headers, HTTP Headers

Accept = 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding = gzip, deflate, br
Accept-Language = en-US,en;q=0.9
Cache-Control = max-age=0
CamelHttpMethod = POST
CamelHttpPath =
CamelHttpQuery = null
CamelHttpServletRequest = Request(POST //localhost:8080/)@37bc1f86
CamelHttpServletResponse = HTTP/1.1 200


CamelHttpUri = /
CamelHttpUrl = http://localhost:8080/
CamelServletContextPath = /
Connection = keep-alive
Content-Length = 20
Content-Type = application/x-www-form-urlencoded
Host = localhost:8080
login = aa
Origin = http://localhost:8080
password = bb
Referer = http://localhost:8080/
sec-ch-ua = "Not.A/Brand";v="8", "Chromium";v="114", "Microsoft Edge";v="114"
sec-ch-ua-mobile = ?0
sec-ch-ua-platform = "Windows"
Sec-Fetch-Dest = document
Sec-Fetch-Mode = navigate
Sec-Fetch-Site = same-origin
Sec-Fetch-User = ?1
Upgrade-Insecure-Requests = 1
User-Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Edg/114.0.1823.43
 End  of Message Headers



I couldn't see an easy method to convert
username=something&password=something (that can possibly be a
workaround). I would say go ahead and open a JIRA ; to see if this is
really a bug.
I did see a slightly different behaviour when I added
disableStreamCache=true; but that did not seem to change other parts.
I did try changing it to a multi-part form and then it showed up as
multiple parts attached - but that would mean changing your approach
completely.


ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account
On Wed, Jun 14, 2023 at 3:14 AM Fyodor Kravchenko  wrote:
>
> Hi Chirag, yeah that exactly is the question - it shouldn't be that way.
>
> If we change Camel version in the pom.xml to Camel 2.24, it'll work as
> expected: the POST payload will be parsed into java.util.Map and the
> Json will be generated (instead of "null").
>
> So the question is -- how do i fix it for camel 3.20.4?
>
> On 13.06.2023 18:04, Chirag wrote:
> > Hi Fyodor,
> > I ran it in IntelliJ thru 3.20.4
> >
> > after submitting page - i got
> >
> > json: null, and string:login=usrename&password=password
> >
> >
> > ચિરાગ/चिराग/Chirag
> > --
> > Sent from My Gmail Account
> >
> > On Mon, Jun 12, 2023 at 7:35 AM Fyodor Kravchenko  
> > wrote:
> >> Hello people,
> >>
> >> any ideas how to fix the issue below?
> >>
> >> -- fedd
> >>
> >> On 09.06.2023 18:15, Fyodor Kravchenko wrote:
> >>> Hello,
> >>>
> >>> I've used to rely on this function in older Camel, when I was able to
> >>> deserialize a regular web form POST stream into a generic
> >>> java.util.Map, I mean, this used to parse the form data (not
> >>> multipart, just regular) and convert into a Map:
> >>>
> >>> Map map = http.getBody(Map.class);
> >>>
> >>> This is my test code snippet that I compile and run on Java 19 of
> >>> GraalVM:
> >>>
> >>> ```
> >>>
> >>>  HttpMessage http =
> >>> exchange.getIn(HttpMessage.class);
> >>>  HttpServletRequest request = http.getRequest();
> >>>  String method = request.getMethod();
> >>>  if ("POST".equals(method) ||
> >>> "PUT".equals(method)) {
> >>>  Map map = http.getBody(Map.class);
> >>>  String string = http.getBody(String.class);
> >>>  http.setHeader(Exchange.CONTENT_TYPE,
> >>> "text/plain");
> >>>  http.setBody("json: " +
> >>> mapper.writeValueAsString(map) + ", and string:" + string);
> >>>  } else {
> >>>  http.setHeader(Exchange.CONTENT_TYPE,
> >>> "text/html");
> >>> http.setBody(this.getClass().getResourceAsStream("form.html"));
> >>>  }
> >>> ```
> >>>
> >>> I've created a test project to make sure it works on Camel 2.24 and
> >>> doesn't in 3.20.4:
> >>>
> >>> https://github.com/fedd/cameljettyformmap/tree/main/cameljettyformmap
> >>>
> >>> I had to add `javax.activation` for the 2.24 version to run, but
> >>> unfortunately that didn't fix the 3.20.4 (See the pom.xml in the
> >>> github link)
> >>>
> >>> What do I have to do to make it work in 3.20.4?
> >>>
> >>> $ java --version
> >>> openjdk 19.0.1 2022-10-18
> >>> OpenJDK Runtime Environment GraalVM CE 22.3.0 (build
> >>> 19.0.1+10-jvmci-22.3-b08)
> >>> OpenJDK 64-Bit Server VM GraalVM CE 22.3.0 (build
> >>> 19.0.1+10-jvmci-22.3-b08, mixed mode, sharing)
> >

Re: Issue in resolving endpoint with property having period

[Claus Ibsen]

Hi

See this FAQ
https://camel.apache.org/manual/faq/how-to-create-executable-jar-camel-main.html#_using_maven_shade_plugin

On Wed, Jun 14, 2023 at 5:10 PM Sujeet Singh 
wrote:

> Hi,
>
> The issue is resolved now.
>
> We loaded the context like below
>
> AbstractApplicationContext context = new
> ClassPathXmlApplicationContext(contextConfigxml);
> context.start();
> context.registerShutdownHook();|
>
> The major factor though was we used below as one of the transformer in
> maven shade plugin.
>
>  implementation="org.apache.maven.plugins.shade.resource.Services
> ResourceTransformer"> 
>
>
> We used Camel 3.40 but if all goes well will move to 3.14.8 as suggested
> here.
>
>
> Thanks all for the help and support.
>
>
> Thanks & Regards,
> Sujeet
>
>
> On Fri, 9 Jun 2023, 16:26 Claus Ibsen,  wrote:
>
> > Hi
> >
> > You are using spring and camel manually where you create spring app
> context
> > and whatnot.
> > Make sure you start spring also, as camel to sync up with spring
> lifecycle
> > and startup its services such as type converters, properties and whatnot.
> >
> > You can only get better help if you put together a small example that
> > reproduces what you do.
> >
> >
> >
> > On Fri, Jun 9, 2023 at 12:13 PM Sujeet Singh  >
> > wrote:
> >
> > > Hi,
> > >
> > > Getting the same issue.
> > >
> > > Extra information is below for this change
> > >
> > > Property with key [time] not found, using default value:  5000
> > >
> > > Thanks & Regards,
> > > Sujeet
> > >
> > > On Fri, 9 Jun 2023, 15:10 Mikael Koskinen,  wrote:
> > >
> > > > Hi,
> > > >
> > > > Does the following syntax work:
> > > >
> > > > from("timer:notification?period={{time:1000}}")
> > > >
> > > > pe 9. kesäk. 2023 klo 12.21 Sujeet Singh (sujeetkumarsi...@gmail.com
> )
> > > > kirjoitti:
> > > > >
> > > > > Hi,
> > > > > The same issue was reported in stackoverflow 11 months ago.
> > > > >
> > > > > java - Using Timer Component with Apache Camel and the period Query
> > > > > Parameter results in error: Error binding property (period=10) with
> > > name:
> > > > > period on bean: - Stack Overflow
> > > > > <
> > > >
> > >
> >
> https://stackoverflow.com/questions/72708073/using-timer-component-with-apache-camel-and-the-period-query-parameter-results-i
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > > Sujeet
> > > > >
> > > > > On Thu, Jun 8, 2023 at 12:56 PM Sujeet Singh <
> > > sujeetkumarsi...@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I switched to 3.14.8 from 3.2.0
> > > > > >
> > > > > > I am getting this extra information which was absent earlier
> > > > > >
> > > > > > Caused by: org.apache.camel.NoTypeConversionAvailableException:
> No
> > > type
> > > > > > converter available to convert from type: java.lang.String to the
> > > > required
> > > > > > type: java.time.Duration with value 5000
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Sujeet
> > > > > >
> > > > > > On Wed, 7 Jun 2023, 19:08 ski n, 
> wrote:
> > > > > >
> > > > > >> It's route information that is needed. If the route xml is
> > provided
> > > > then
> > > > > >> it's easier to take a look at it.
> > > > > >>
> > > > > >> BTW are you really running it on 3.2.0? (It's best to use
> 3.20.5,
> > or
> > > > at
> > > > > >> least to go to 3.14.8)
> > > > > >>
> > > > > >> On Wed, Jun 7, 2023 at 3:30 PM Sujeet Singh <
> > > > sujeetkumarsi...@gmail.com>
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Hi,
> > > > > >> >
> > > > > >> > It is something like below.
> > > > > >> >
> > > > > >> > public class FeedLauncher{
> > > > > >> > public static void main(String[] args){
> > > > > >> >ApplicationContext context =
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > >
> > >
> >
> ClassPathXmlApplicationContext("spring/tc-feedloader-camel-spring-ctx.xml");
> > > > > >> >SpringCamelContext camleContext = new SpringCamelContext();
> > > > > >> >camelContext.setApplicationContext(context);
> > > > > >> >camelContext.start();
> > > > > >> > }
> > > > > >> > tc-feedloader-camel-spring-ctx.xml
> > > > > >> > 
> > > > > >> > 
> > > > > >> >  > > > resource="classpath:spring/feedloader-camel-spring-ctx.xml"/>
> > > > > >> >  > > > > >> >
> > > > resource="classpath:spring/tc-feedloader-idempotent-spring-ctx.xml"/>
> > > > > >> >  resource="classpath:spring/tc-feedloader-context.xml"/>
> > > > > >> > 
> > > > > >> > tc-feedloader-context.xml
> > > > > >> > 
> > > > > >> > 
> > > > > >> >  resource="classpath:spring/${ENV}/tbus-mq-context.xml"/>
> > > > > >> >  > > > > >> >   base-package=""/>
> > > > > >> > 
> > > > > >> >
> > > > > >> >
> > > > > >> > The route information is stored in database and using JPA we
> are
> > > > > >> extracting
> > > > > >> > and configuring it.
> > > > > >> >
> > > > > >> > We are really stuck on this though it works very well with
> Camel
> > > 2.x
> > > > > >> >
> > > > > >> > Thanks & Regards,
> > > > > >> > Sujeet
> > > > > >> >
> > > > > >> >
> > > > > >> >
> 

Re: Issue in resolving endpoint with property having period

[Sujeet Singh]

Hi,

The issue is resolved now.

We loaded the context like below

AbstractApplicationContext context = new
ClassPathXmlApplicationContext(contextConfigxml);
context.start();
context.registerShutdownHook();|

The major factor though was we used below as one of the transformer in
maven shade plugin.

 


We used Camel 3.40 but if all goes well will move to 3.14.8 as suggested
here.


Thanks all for the help and support.


Thanks & Regards,
Sujeet


On Fri, 9 Jun 2023, 16:26 Claus Ibsen,  wrote:

> Hi
>
> You are using spring and camel manually where you create spring app context
> and whatnot.
> Make sure you start spring also, as camel to sync up with spring lifecycle
> and startup its services such as type converters, properties and whatnot.
>
> You can only get better help if you put together a small example that
> reproduces what you do.
>
>
>
> On Fri, Jun 9, 2023 at 12:13 PM Sujeet Singh 
> wrote:
>
> > Hi,
> >
> > Getting the same issue.
> >
> > Extra information is below for this change
> >
> > Property with key [time] not found, using default value:  5000
> >
> > Thanks & Regards,
> > Sujeet
> >
> > On Fri, 9 Jun 2023, 15:10 Mikael Koskinen,  wrote:
> >
> > > Hi,
> > >
> > > Does the following syntax work:
> > >
> > > from("timer:notification?period={{time:1000}}")
> > >
> > > pe 9. kesäk. 2023 klo 12.21 Sujeet Singh (sujeetkumarsi...@gmail.com)
> > > kirjoitti:
> > > >
> > > > Hi,
> > > > The same issue was reported in stackoverflow 11 months ago.
> > > >
> > > > java - Using Timer Component with Apache Camel and the period Query
> > > > Parameter results in error: Error binding property (period=10) with
> > name:
> > > > period on bean: - Stack Overflow
> > > > <
> > >
> >
> https://stackoverflow.com/questions/72708073/using-timer-component-with-apache-camel-and-the-period-query-parameter-results-i
> > > >
> > > >
> > > > Thanks & Regards,
> > > > Sujeet
> > > >
> > > > On Thu, Jun 8, 2023 at 12:56 PM Sujeet Singh <
> > sujeetkumarsi...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I switched to 3.14.8 from 3.2.0
> > > > >
> > > > > I am getting this extra information which was absent earlier
> > > > >
> > > > > Caused by: org.apache.camel.NoTypeConversionAvailableException: No
> > type
> > > > > converter available to convert from type: java.lang.String to the
> > > required
> > > > > type: java.time.Duration with value 5000
> > > > >
> > > > > Thanks & Regards,
> > > > > Sujeet
> > > > >
> > > > > On Wed, 7 Jun 2023, 19:08 ski n,  wrote:
> > > > >
> > > > >> It's route information that is needed. If the route xml is
> provided
> > > then
> > > > >> it's easier to take a look at it.
> > > > >>
> > > > >> BTW are you really running it on 3.2.0? (It's best to use 3.20.5,
> or
> > > at
> > > > >> least to go to 3.14.8)
> > > > >>
> > > > >> On Wed, Jun 7, 2023 at 3:30 PM Sujeet Singh <
> > > sujeetkumarsi...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > It is something like below.
> > > > >> >
> > > > >> > public class FeedLauncher{
> > > > >> > public static void main(String[] args){
> > > > >> >ApplicationContext context =
> > > > >> >
> > > > >> >
> > > > >>
> > >
> >
> ClassPathXmlApplicationContext("spring/tc-feedloader-camel-spring-ctx.xml");
> > > > >> >SpringCamelContext camleContext = new SpringCamelContext();
> > > > >> >camelContext.setApplicationContext(context);
> > > > >> >camelContext.start();
> > > > >> > }
> > > > >> > tc-feedloader-camel-spring-ctx.xml
> > > > >> > 
> > > > >> > 
> > > > >> >  > > resource="classpath:spring/feedloader-camel-spring-ctx.xml"/>
> > > > >> >  > > > >> >
> > > resource="classpath:spring/tc-feedloader-idempotent-spring-ctx.xml"/>
> > > > >> > 
> > > > >> > 
> > > > >> > tc-feedloader-context.xml
> > > > >> > 
> > > > >> > 
> > > > >> > 
> > > > >> >  > > > >> >   base-package=""/>
> > > > >> > 
> > > > >> >
> > > > >> >
> > > > >> > The route information is stored in database and using JPA we are
> > > > >> extracting
> > > > >> > and configuring it.
> > > > >> >
> > > > >> > We are really stuck on this though it works very well with Camel
> > 2.x
> > > > >> >
> > > > >> > Thanks & Regards,
> > > > >> > Sujeet
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Jun 5, 2023 at 7:37 PM ski n 
> > > wrote:
> > > > >> >
> > > > >> > > Hi Sujeet,
> > > > >> > >
> > > > >> > > Can you add the complete route, so it's clear where you are
> > using
> > > it?
> > > > >> > >
> > > > >> > > Regards,
> > > > >> > >
> > > > >> > > Raymond
> > > > >> > >
> > > > >> > > On Mon, Jun 5, 2023 at 3:50 PM Sujeet Singh <
> > > > >> sujeetkumarsi...@gmail.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > I am trying to migrate from Camel 2.x to
> > > > >> > > > Camel 3.2.0. I have followed all the
> > > > >> > > > guidelines but getting the below error
> > > > >> > > > during st

Re: [VOTE] Release Apache Camel K 1.12.1 and Camel K runtime 1.17.1 - second attempt

[Pasquale Congiusti]

Thanks all folks.

I forgot to send an email and close this voting as passed.

Cheers,
Pasquale.

On Wed, Jun 7, 2023 at 2:56 PM Pasquale Congiusti <
pasquale.congiu...@gmail.com> wrote:

> Hello,
>
> This is a combined vote to release Apache Camel K 1.12.1 and Camel K
> Runtime1.17.1. The release also contains the Camel K CRD 1.12.1, a Java
> client for Kubernetes Camel K CRDs. The release is based on Camel 3.20.x
> and Camel Quarkus 2.16.x. It contains mostly bug fixes. A first attempt to
> release this version was canceled last week due to a bug found while
> testing the staging version.
>
> Camel K Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.17.1/
>
> Camel K Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1565
>
> Camel K Runtime Tag:
>
> https://github.com/apache/camel-k-runtime/releases/tag/camel-k-runtime-project-1.17.1
>
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.12.1/
>
> Camel K Tag:
> https://github.com/apache/camel-k/releases/tag/v1.12.1
>
> Camel K CRD Java dependency staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1566
>
> Staging container image repository:
>
> https://hub.docker.com/layers/camelk/camel-k/1.12.1/images/sha256-34b0ea1de619b1790fce1031dcd332f4be1429c045fab30dfe60d589554f842c?context=repo
>
> It's possible to install all staging artifacts with a single command
> (preferably using the kamel CLI you find in Camel K release files):
>
> kamel install --operator-image=camelk/camel-k:1.12.1 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1565
>  --olm=false
>
> Please test this release candidate and cast your vote.
>
> [ ] +1 Release the binary as Apache Camel K 1.12.1 and Apache Camel K
> Runtime 1.17.1
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> I start the vote with my +1.
>
> Thanks and regards,
> Pasquale Congiusti
>

Re: 3.20.4 Bug(?): Route's ErrorHandler not working if exception happens on Kamelet

[Mikael Koskinen]

Hi,

Great to hear, thank you!

On Tuesday, June 13, 2023, Claus Ibsen  wrote:

> Hi
>
> Okay so your use-cases will then work out of the box in 3.20.6 onwards.
>
> On Tue, Jun 13, 2023 at 2:59 PM Claus Ibsen  wrote:
>
> > Hi
> >
> > I tracked down what I consider a little bug
> > https://issues.apache.org/jira/browse/CAMEL-19443
> >
> > With the bug fix then this use-case from Mikael works on 3.20.x as well.
> >
> > The other ticket CAMEL-19411 to regard kameelts as "black box" still
> > stands. However this is maybe a different concept that regular route
> > templates that would not.
> > So we may need to consider CAMEL-19411 whether we want to do this in
> Camel
> > v4 or not.
> >
> >
> >
> > On Sat, Jun 3, 2023 at 10:48 AM Claus Ibsen 
> wrote:
> >
> >> Hi
> >>
> >> Yes its a good idea to make kamelets like a "black box" and they should
> >> not have any error handling (noErrorHandler), then
> >> they are like calling a component.
> >>
> >> We can add an option to the kamelet component that can turn on old
> >> behaviour for users that somehow want the old way (just in case).
> >> https://issues.apache.org/jira/browse/CAMEL-19411
> >>
> >>
> >> On Fri, Jun 2, 2023 at 11:40 AM Mikael Koskinen 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Thank you for the replies. It would be great if the Kamelets could
> >>> inherit the configuration as modifying the Kamelet specifications is
> >>> mostly out of the question as we're using the stock/built-in Kamelets,
> >>> like http-sink etc. I think this is quite a big issue (for me at least
> >>> :)) as it means that we really can't use the Kamelets from our routes
> >>> if we need to deal with errors in a specific way. And we do. The
> >>> documentation states that the Kamelet should act like a
> >>> direct-component but in this regard it doesn't.
> >>>
> >>> Without knowing the internals of Apache Camel that well, I wonder if
> >>> this is something that could be changed on how the Kamelet Component
> >>> is implemented? Would it be possible to pass the route configuration
> >>> to the RouteDefinition, which is (I think) created in the
> >>> Kamelet.java/templateToRoute?
> >>>
> >>> Best regards,
> >>> Mikael
> >>>
> >>> pe 2. kesäk. 2023 klo 11.10 Andrea Cosentino (anco...@gmail.com)
> >>> kirjoitti:
> >>> >
> >>> > But it's not with kamelets it's a plain route
> >>> >
> >>> > Il ven 2 giu 2023, 10:08 Andrea Cosentino  ha
> >>> scritto:
> >>> >
> >>> > > There is one example in the camel-kamelets-example repo:
> >>> > >
> >>> > >
> >>> > >
> >>> https://github.com/apache/camel-kamelets-examples/tree/
> main/jbang/error-handler
> >>> > >
> >>> > > Il ven 2 giu 2023, 10:03 Pasquale Congiusti <
> >>> pasquale.congiu...@gmail.com>
> >>> > > ha scritto:
> >>> > >
> >>> > >> Hello,
> >>> > >> Error handler should be managed differently in Kamelets. Basically
> >>> the
> >>> > >> problem is that a Kamelet is a RouteTemplate, so it is like a new
> >>> Route
> >>> > >> and
> >>> > >> won't "inherit" the configuration you've defined in the original
> >>> route. I
> >>> > >> think you need to define your error inside the Kamelet
> specification
> >>> > >> (which
> >>> > >> it's not a very nice design). In Camel K, we've created a layer on
> >>> top of
> >>> > >> it inside the runtime, in order to let the user define the error
> >>> handling
> >>> > >> in the Binding [1].
> >>> > >>
> >>> > >> We had some draft work [2] to enhance that, expecting a similar
> >>> global
> >>> > >> mechanism in Camel. However, I haven't followed by near the recent
> >>> > >> developments in Camel 4 to tell you if this is going to be
> included
> >>> in the
> >>> > >> new version or not.
> >>> > >>
> >>> > >> Regards,
> >>> > >> Pasquale.
> >>> > >>
> >>> > >> [1]
> >>> > >>
> >>> > >>
> >>> https://camel.apache.org/camel-k/1.12.x/kamelets/
> kameletbindings-error-handler.html
> >>> > >> [2] https://github.com/apache/camel-k-runtime/pull/868
> >>> > >>
> >>> > >> On Fri, Jun 2, 2023 at 7:35 AM Mikael Koskinen <
> mijap...@gmail.com>
> >>> > >> wrote:
> >>> > >>
> >>> > >> > Hey,
> >>> > >> >
> >>> > >> > I wonder if anyone has any info regarding this issue? It's
> >>> possible
> >>> > >> > (and maybe quite likely!) that I'm using the
> >>> > >> > routeConfiguration/errorHandler incorrectly.
> >>> > >> >
> >>> > >> > Thanks in advance.
> >>> > >> >
> >>> > >> > Best regards,
> >>> > >> > Mikael
> >>> > >> >
> >>> > >> > pe 19. toukok. 2023 klo 15.24 Mikael Koskinen (
> mijap...@gmail.com
> >>> )
> >>> > >> > kirjoitti:
> >>> > >> > >
> >>> > >> > > Hi,
> >>> > >> > >
> >>> > >> > > I'm encountering a problem where route configuration's error
> >>> handler
> >>> > >> > > isn't run if the exception happens on a Kamelet. Here's the
> >>> gist with
> >>> > >> > > tries to show the issue:
> >>> > >> > >
> >>> > >> >
> >>> > >>
> >>> https://gist.githubusercontent.com/mikoskinen/
> 4e3e3a8efdf891890a2a46dfddae1d48/raw/09055bcdc1c2252a77a069fcebd07d
> 6f727db555/camel-yaml-kamelet-errorhandling.yaml
> >>> > 

Re: [VOTE] Release Apache Camel K 1.12.1 and Camel K runtime 1.17.1 - second attempt

[Nicolas Filotto]

Hi,

+1 (binding)

Thank you Pasquale,
Regards,
Nicolas

From: Pasquale Congiusti 
Sent: Wednesday, June 7, 2023 14:56
To: dev ; users@camel.apache.org 
Subject: [VOTE] Release Apache Camel K 1.12.1 and Camel K runtime 1.17.1 - 
second attempt

Hello,

This is a combined vote to release Apache Camel K 1.12.1 and Camel K
Runtime1.17.1. The release also contains the Camel K CRD 1.12.1, a Java
client for Kubernetes Camel K CRDs. The release is based on Camel 3.20.x
and Camel Quarkus 2.16.x. It contains mostly bug fixes. A first attempt to
release this version was canceled last week due to a bug found while
testing the staging version.

Camel K Runtime source files:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.17.1/__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFNnJli2nA$

Camel K Runtime staging repository:
https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachecamel-1565__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFODumvEhA$

Camel K Runtime Tag:
https://urldefense.com/v3/__https://github.com/apache/camel-k-runtime/releases/tag/camel-k-runtime-project-1.17.1__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFOO-6LU5Q$

Camel K release files:
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/camel/camel-k/1.12.1/__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFOykmNzOQ$

Camel K Tag:
https://urldefense.com/v3/__https://github.com/apache/camel-k/releases/tag/v1.12.1__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFMlFqejww$

Camel K CRD Java dependency staging repository:
https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachecamel-1566__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFM_Jf9mjw$

Staging container image repository:
https://urldefense.com/v3/__https://hub.docker.com/layers/camelk/camel-k/1.12.1/images/sha256-34b0ea1de619b1790fce1031dcd332f4be1429c045fab30dfe60d589554f842c?context=repo__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFNGQ39IOA$

It's possible to install all staging artifacts with a single command
(preferably using the kamel CLI you find in Camel K release files):

kamel install --operator-image=camelk/camel-k:1.12.1 --maven-repository=
https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachecamel-1565__;!!CiXD_PY!T3KvVNNpUdxgy9U-GQo0XWRwQum1hJ6O3eT849jnql39SmiYuidopAvMaz128MfMHIx4IjXcP_kauk_pPFODumvEhA$
 --olm=false

Please test this release candidate and cast your vote.

[ ] +1 Release the binary as Apache Camel K 1.12.1 and Apache Camel K
Runtime 1.17.1
[ ] -1 Veto the release (provide specific comments)

The vote is open for at least 72 hours.

I start the vote with my +1.

Thanks and regards,
Pasquale Congiusti

As a recipient of an email from the Talend Group, your personal data will be 
processed by our systems. Please see our Privacy Notice 
 for more information about our 
collection and use of your personal information, our security practices, and 
your data protection rights, including any rights you may have to object to 
automated-decision making or profiling we use to analyze support or marketing 
related communications. To manage or discontinue promotional communications, 
use the communication preferences 
portal. To exercise your data 
protection rights, use the privacy request 
form.
 Contact us here  or by mail to either of our 
co-headquarters: Talend, Inc.: 400 South El Camino Real, Ste 1400, San Mateo, 
CA 94402; Talend SAS: 5/7 rue Salomon De Rothschild, 92150 Suresnes, France

Re: [VOTE] Release Apache Camel K 1.12.1 and Camel K runtime 1.17.1 - second attempt

[Babak Vahdat]

+1 (binding)

Thanks Pasquale!

--
Babak

> On 7 Jun 2023, at 14:56, Pasquale Congiusti  
> wrote:
> 
> Hello,
> 
> This is a combined vote to release Apache Camel K 1.12.1 and Camel K
> Runtime1.17.1. The release also contains the Camel K CRD 1.12.1, a Java
> client for Kubernetes Camel K CRDs. The release is based on Camel 3.20.x
> and Camel Quarkus 2.16.x. It contains mostly bug fixes. A first attempt to
> release this version was canceled last week due to a bug found while
> testing the staging version.
> 
> Camel K Runtime source files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k-runtime/1.17.1/
> 
> Camel K Runtime staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1565
> 
> Camel K Runtime Tag:
> https://github.com/apache/camel-k-runtime/releases/tag/camel-k-runtime-project-1.17.1
> 
> Camel K release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-k/1.12.1/
> 
> Camel K Tag:
> https://github.com/apache/camel-k/releases/tag/v1.12.1
> 
> Camel K CRD Java dependency staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1566
> 
> Staging container image repository:
> https://hub.docker.com/layers/camelk/camel-k/1.12.1/images/sha256-34b0ea1de619b1790fce1031dcd332f4be1429c045fab30dfe60d589554f842c?context=repo
> 
> It's possible to install all staging artifacts with a single command
> (preferably using the kamel CLI you find in Camel K release files):
> 
> kamel install --operator-image=camelk/camel-k:1.12.1 --maven-repository=
> https://repository.apache.org/content/repositories/orgapachecamel-1565
> --olm=false
> 
> Please test this release candidate and cast your vote.
> 
> [ ] +1 Release the binary as Apache Camel K 1.12.1 and Apache Camel K
> Runtime 1.17.1
> [ ] -1 Veto the release (provide specific comments)
> 
> The vote is open for at least 72 hours.
> 
> I start the vote with my +1.
> 
> Thanks and regards,
> Pasquale Congiusti

Re: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4

[Fyodor Kravchenko]

Hi Chirag, yeah that exactly is the question - it shouldn't be that way.

If we change Camel version in the pom.xml to Camel 2.24, it'll work as 
expected: the POST payload will be parsed into java.util.Map and the 
Json will be generated (instead of "null").


So the question is -- how do i fix it for camel 3.20.4?

On 13.06.2023 18:04, Chirag wrote:

Hi Fyodor,
I ran it in IntelliJ thru 3.20.4

after submitting page - i got

json: null, and string:login=usrename&password=password


ચિરાગ/चिराग/Chirag
--
Sent from My Gmail Account

On Mon, Jun 12, 2023 at 7:35 AM Fyodor Kravchenko  wrote:

Hello people,

any ideas how to fix the issue below?

-- fedd

On 09.06.2023 18:15, Fyodor Kravchenko wrote:

Hello,

I've used to rely on this function in older Camel, when I was able to
deserialize a regular web form POST stream into a generic
java.util.Map, I mean, this used to parse the form data (not
multipart, just regular) and convert into a Map:

Map map = http.getBody(Map.class);

This is my test code snippet that I compile and run on Java 19 of
GraalVM:

```

 HttpMessage http =
exchange.getIn(HttpMessage.class);
 HttpServletRequest request = http.getRequest();
 String method = request.getMethod();
 if ("POST".equals(method) ||
"PUT".equals(method)) {
 Map map = http.getBody(Map.class);
 String string = http.getBody(String.class);
 http.setHeader(Exchange.CONTENT_TYPE,
"text/plain");
 http.setBody("json: " +
mapper.writeValueAsString(map) + ", and string:" + string);
 } else {
 http.setHeader(Exchange.CONTENT_TYPE,
"text/html");
http.setBody(this.getClass().getResourceAsStream("form.html"));
 }
```

I've created a test project to make sure it works on Camel 2.24 and
doesn't in 3.20.4:

https://github.com/fedd/cameljettyformmap/tree/main/cameljettyformmap

I had to add `javax.activation` for the 2.24 version to run, but
unfortunately that didn't fix the 3.20.4 (See the pom.xml in the
github link)

What do I have to do to make it work in 3.20.4?

$ java --version
openjdk 19.0.1 2022-10-18
OpenJDK Runtime Environment GraalVM CE 22.3.0 (build
19.0.1+10-jvmci-22.3-b08)
OpenJDK 64-Bit Server VM GraalVM CE 22.3.0 (build
19.0.1+10-jvmci-22.3-b08, mixed mode, sharing)