Hi
again thanks. Your post clarifies a lot of dark corners for me. I will
play with @BeanParam also
One question though
in 4) you said
When we deal with JAX-RS parameters representing parts of URI or headers
or individual form parameters we deal with plain strings that have no
associated media type information. JAX-RS message body readers/writers
need that info. Also parameters are handled earlier than message bodies,
they have different processing chains
So the problem is that CXF doesn't know the mediatype - if the payload
is json or xml or whatever?
The @Produces @Consumes aren't helping in that regard?
And the way to let CXF know is to provide a custom form (in my case)
provider? Are we talking jax-rs providers or CXF interceptors for this?
Is there an example of this anywhere?
My guess was that CXF doesn't know the Entity.class during the
conversion. Thanks for clearing that up.
Really really thanks for the leads and the insightful information.
Vassilis
In case you wonder - I am trying to use RestyGWT with CXF.
On 06/26/2014 01:27 PM, Sergey Beryozkin wrote:
Hi
On 26/06/14 10:15, Vassilis Virvilis wrote:
Hi Sergey,
First of all thanks for answering because I am banging my head against
the wall for 3 days now with this to the point that all my google
searches have turned pink (page already visited).
If I understood correctly you are telling me that I need
ParamConverterProvider
http://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/ParamConverterProvider.html
I suppose I can do that and I hope I will be able to register it through
the web.xml (I am using nonspringservlet). The documentation is a bit
sparse but I believe I will manage it.
You can register ParamConverterProvider implementation with
CXFNonSpringJaxrsServlet
What I need to understand is the following
JAX-RS MessageBodyReader is not involved into reading individual
parameters, it can only handle a method parameter representing a
complete HTML request body, i.e. the parameters without JAX-RS
annotations like PathParam, HeaderParam or FormParam.
Qustions:
1) If I don't use @FormParam or POST: Do I still need to have my own
ParamConverterProvider? or it will be handled automatically by CXF?
You only need it if you have a non primitive parameter type in the
signature
2) Or do you mean I must tag it like this @FormParam("") since only one
parameter can be in the post form (body) ?
Using "" as a parameter value is a CXF specific extension and it uses a
different mechanism, it injects all the available optional
(form/queries/headers) into a bean, JAX-RS 2.0 offers a BeanParam
annotation
3) I have to create a ParamConverterProvider for all my custom objects?
Only for non-primitive parameters, those not supporting a default
conversion mechanism (they have no no String factory constructors/valueOf)
4) What is missing and CXF cannot do it automagically like it does it
with aegis and SOAP given that the outgoing Entity (return value )
through JAX-RS is working all right.
When we deal with JAX-RS parameters representing parts of URI or headers
or individual form parameters we deal with plain strings that have no
associated media type information. JAX-RS message body readers/writers
need that info. Also parameters are handled earlier than message bodies,
they have different processing chains
If you have a form payload you can also register a custom form provider
which will extract a given form field value and pass it to a registered
MessageBodyReader via the injected Providers context, passing some hard
coded MediaType value (example, you know the value is a JSON sequence)
Cheers, Sergey
Any links for further reading on this you may have are much appreciated.
Again thanks for your help.
Vassilis Virvilis
On 06/25/2014 03:53 PM, Sergey Beryozkin wrote:
Hi
On 25/06/14 13:47, Vassilis Virvilis wrote:
Hi,
My problem looks like this
http://mail-archives.apache.org/mod_mbox/cxf-users/201307.mbox/%[email protected]%3E
I am using cxf 3.0.0 so I believe the thread does not apply and I am
not
sure what I should do or try based on that thread.
My problem is that I am trying to call
@POST
@Path("existing-entity")
@Consumes("application/x-www-form-urlencoded")
public Entity getExistingEntity(
@FormParam("entity") Entity entity)
throws SQLException;
with an entity and the service is instantiating the Entity based on
String constructor which looks like a fallback CXF strategy around
./rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/InjectionUtils.java:393
The jackson provider is not called to do the deserialization. I don't
know why. Similarly as the link I provide above if I pass the json
payload that the client is sending to objectMapper.getValue(json,
Entity.class) everything works correctly.
So the question is why jackson is not involved during deserialization?.
JAX-RS MessageBodyReader is not involved into reading individual
parameters, it can only handle a method parameter representing a
complete HTML request body, i.e. the parameters without JAX-RS
annotations like PathParam, HeaderParam or FormParam.
You need to register JAX-RS 2.0 ParamConverterProvider for Entity which
will use Jackson mapper to convert a given String value into Entity
HTH, Sergey
It works fine for serialization.
My guess the fail is in somewhere around InjectionUtils.java:358
Object result = createFromParameterHandler(value, pClass,
paramAnns, message);
if (result != null) {
return pClass.cast(result);
}
but I don't know enough to debug this.
Vassilis
--
__________________________________
Vassilis Virvilis Ph.D.
Head of IT
Biovista Inc.
US Offices
2421 Ivy Road
Charlottesville, VA 22903
USA
T: +1.434.971.1141
F: +1.434.971.1144
European Offices
34 Rodopoleos Street
Ellinikon, Athens 16777
GREECE
T: +30.210.9629848
F: +30.210.9647606
www.biovista.com
Biovista is a privately held biotechnology company that finds novel uses
for existing drugs, and profiles their side effects using their
mechanism of action. Biovista develops its own pipeline of drugs in CNS,
oncology, auto-immune and rare diseases. Biovista is collaborating with
biopharmaceutical companies on indication expansion and de-risking of
their portfolios and with the FDA on adverse event prediction.
