Hi
I guess you can not make it work reliably with @BeanParam bean.
First of all if a given method has a JAX-RS annotation then the
superclasses are not checked, this is per the annotation inheritance
spec restriction. And perhaps you can get the ordering of methods being
different with various JDKs.
Perhaps you can make it work with something like:
@Consumes("application/x-www-form-urlencoded")
post(@Context UriInfo ui, MultivaluedMap<String, String> formPayload) {
String a = getParam(ui, formPayload, "a");
}
String get(UriInfo ui, MultivaluedMap<String, String> formPayload,
String paramName) {
String value = ui.getQueryParameters().getFirst(paramName);
return value != null ? value : formPayload.getFirst(paramName);
}
Sergey
On 26/01/16 08:36, Julien Charon wrote:
Hi,
Recently, I had time to have a closer look at this. I first analysed the
behaviour of the old implementation using
(Http)ServletRequest.getParameter(String).
I observed that it is possible to mix both parameters provided in the URL and
in the body of the request, whereas the parameters in the URL are preferred to
the ones in the body.
For example, assuming a service method with 3 parameters param1, param2 and
param3:
URL: http://server1/service/method?param1=urlValue1¶m2=urlValue2
Body: param2=bodyValue2¶m3=bodyValue3
Then (Http)ServletRequest.getParameter(String) will return: param1=urlValue1,
param2=urlValue2 and param3=bodyValue3
So I tried to create a bean param class for a GET method containing @QueryParam
annotations on the setters. In a second step, I created a subclass of the bean
param class to use it for a POST method with application/x-www-form-urlencoded
by overriding the setters and annotating them with @FormParam using the same
parameter names. Now this is working fine as long as parameters are not mixed
like I described it above. I think this is logical because I overwrote the
setters and replaced the annotation. So I tried to create new setter methods
with a suffix, annotated those with @FormParam and make them call the setter of
the superclass. Unfortunately, this doesn't work.
Does someone have an idea how I can achieve the behaviour of the old
implementation?
Viele Grüße,
Julien
Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.cha...@avitech.aero
________________________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
Court Registration: Amtsgericht Ulm | HRB 728293
Geschäftsführer/Managing Director: Antonio Maria Gonzalez Gorostiza
http://avitech.aero
This message may contain confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
-----Ursprüngliche Nachricht-----
Von: Julien Charon [mailto:julien.cha...@avitech.aero]
Gesendet: Donnerstag, 10. Dezember 2015 15:51
An: users@cxf.apache.org
Betreff: AW: CXF 3.0.7 JAXRS POST application/x-www-form-urlencoded
Thank you. So I will wait for 3.0.8.
However, I noticed another behaviour related to using HttpServletRequest but
with content type text/xml. If javax.servlet.ServletRequest.getInputStream() is
called, an InputStream is returned that contains no data, i.e. I can't access
the body of the POST request. Anything else I can do to avoid that than getting
the body as method parameter?
Best regards,
Julien
Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.cha...@avitech.aero
________________________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany Court
Registration: Amtsgericht Ulm | HRB 728293 Geschäftsführer/Managing Director:
Antonio Maria Gonzalez Gorostiza http://avitech.aero
This message may contain confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
-----Ursprüngliche Nachricht-----
Von: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Gesendet: Sonntag, 6. Dezember 2015 18:47
An: users@cxf.apache.org
Betreff: Re: CXF 3.0.7 JAXRS POST application/x-www-form-urlencoded
FYI:
https://issues.apache.org/jira/browse/CXF-6679
Sergey
On 04/12/15 11:59, Sergey Beryozkin wrote:
Hi
Thanks for experimenting with CXF,
https://issues.apache.org/jira/browse/CXF-6679
is open and I'm honestly not sure why it is not working because CXF
itself does not consume that data, so if it works directly with the
servlet then it should work inside the JAX-RS code.
Unless CXF does some internal caching before the stream even consumed
by the application, hmm, need to check that...
That said, I;d recommend avoiding using HttpServletRequest and simply
have MultivaluedMap in the method signature or @FormParams if a number
of parameters is not open ended.
I'll look at CXF-6679 asap
Sergey
On 04/12/15 08:35, Julien Charon wrote:
Hi everybody,
A couple of days ago I started refactoring one of our applications to
use CXF / JAX-RS. Until then the entry point of the application was
an implementation of javax.servlet.http.HttpServlet that was deployed
to tomcat extracting all information needed using the doPost and
doGet methods and the HttpServletRequest / HttpServletResponse
parameters directly.
Now I refactored that usind a CXFNonSpringServlet and moving the
implementation to a service class with 2 methods annotated with @POST
/ @GET and, again, 2 parameters HttpServletRequest /
HttpServletResponse with the help of the @Context annotation.
Everything went smooth, so I started doing some regression tests and
noticed a different behaviour of the new implementation compared to
the new one: I send a POST request with Content-Type
application/x-www-form-urlencoded and defining some parameters in the
body of the request instead of passing them directly as parameters in
the URL. The "old" implementation will get all parameters defined in
the body by calling (Http)ServletRequest.getParameter(String) but the
new one will not. Actually, it looks like no parameters were defined
at all.
I really would like to void to read the body and parse it to extract
the parameters defined in there. Is there a logic explanation for
that behaviour? Do I need to define an Interceptor or something similar?
Any help/clarification would be appreciated.
Best regards,
Julien
Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.cha...@avitech.aero<mailto:julien.cha...@avitech.aero>
________________________________________________
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Friedrichshafen | Germany
Court Registration: Amtsgericht Ulm | HRB 728293
Geschäftsführer/Managing Director: Antonio Maria Gonzalez Gorostiza
http://avitech.aero<http://avitech.aero/>
This message may contain confidential information and is intended
only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
