You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Fyodor Kravchenko <fe...@hotmail.com> on 2023/06/09 15:15:07 UTC
HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Fyodor Kravchenko <fe...@hotmail.com>.
Hi Chirag,
thanks for helping! I'm a bit lost, I think I'll follow your previous
advice and file a jira. I'm embedding Camel and it has to work as in my
examples. Thanks again!
-fedd
On 20.06.2023 17:45, Chirag wrote:
> moved both under one gist
> https://gist.github.com/chiragsanghavi/02a00f49ac7ee9a978344af571746c02
>
> ચિરાગ/चिराग/Chirag
> ------------------------------------------
> Sent from My Gmail Account
>
> On Thu, Jun 15, 2023 at 12:06 AM Chirag <ch...@gmail.com> wrote:
>> @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 <ch...@gmail.com> 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 <fe...@hotmail.com> 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<String,Object> 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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Chirag <ch...@gmail.com>.
moved both under one gist
https://gist.github.com/chiragsanghavi/02a00f49ac7ee9a978344af571746c02
ચિરાગ/चिराग/Chirag
------------------------------------------
Sent from My Gmail Account
On Thu, Jun 15, 2023 at 12:06 AM Chirag <ch...@gmail.com> wrote:
>
> @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 <ch...@gmail.com> 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 <fe...@hotmail.com> 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<String,Object> 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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Chirag <ch...@gmail.com>.
@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 <ch...@gmail.com> 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 <fe...@hotmail.com> 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<String,Object> 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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Chirag <ch...@gmail.com>.
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 <fe...@hotmail.com> 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<String,Object> 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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Fyodor Kravchenko <fe...@hotmail.com>.
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<String,Object> 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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Chirag <ch...@gmail.com>.
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 <fe...@hotmail.com> 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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Fyodor Kravchenko <fe...@hotmail.com>.
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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Chirag <ch...@gmail.com>.
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 <fe...@hotmail.com> 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: HttpMessage.getBody(Map.class) stopped working when migrated from Camel 2 to 3.20.4
Posted by Fyodor Kravchenko <fe...@hotmail.com>.
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)
>