| Hi Andy,
I understand how this can be interpreted in different ways. In general, I think running interceptors is useful, but we may need to clarify this either way.
Do you handle the type Form in a special manner too? E.g., if a client does a post using Form, is the interceptor chain called?
— Santiago
Hi Christian, Santiago,
I might be taking the spec too literally, but I would view that the @FormParam annotation indicates that foobar is a parameter, not an entity. The JAX-RS spec shows that the MBR interceptor chain is optional in Appendix C. In this case, I think CXF is optimizing the pipeline since it does not see an entity. If I expand on the example code and use a ParamConverterProvider/ParamConverter, I see that CXF invokes them - allowing me to manipulate the value that is ultimately passed to the post method. I think that this should be the proper way to "intercept" @FormParam (or any other @*Param parameters).
Similarly, CXF will invoke the MBR and ReaderInterceptor if I remove the @FormParam annotation from the parameter - IMO, that changes the foobar parameter from being a parameter to to being an entity.
Christian, would it be possible for you to try those options too? (1) Remove @FormParam and process foobar as an entity and (2) Use a ParamConverterProvider to process foobar as a parameter?
Here is the ParamConverterProvider I used: @Provider public class MyParamConverterProvider implements ParamConverterProvider { private final static Logger _log = Logger.getLogger(MyParamConverterProvider.class.getName());
@SuppressWarnings("unchecked") @Override public <T> ParamConverter<T> getConverter(Class<T> aClass, Type type, Annotation[] annos) { _log.info("getConverter"); if(String.class.isAssignableFrom(aClass)) { return (ParamConverter<T>) new ParamConverter<String>(){
@Override public java.lang.String toString(String s) { return "toString"+s; }
@Override public String fromString(String s) { _log.info("fromString " + s); return "fromString" + s; }}; } return null; } }
Thanks,
Andy
Hi Christian,
What would be the rationale for not invoking the interceptor? If there’s an entity and a MBR, there should be a (possibly empty) interceptor chain.
— Santiago
Hi all,
I've a quick question and would love to get your feedback.
Let's assume there is ReaderInterceptor like this:
@Provider public class MyReaderInterceptor implements ReaderInterceptor {
public Object aroundReadFrom(ReaderInterceptorContext context) { // do stuff }
}
And the following JAX-RS resource class:
@Path("some-path")
public class SomeResource {
@POST
public Response post(@FormParam("foobar") String foobar) {
// do stuff }
}
If a client sends a POST request to the resource and submits the form parameter in the body, would you expect the ReaderInterceptor to get invoked or not?
I'm asking because JAX-RS implementations handle this case differently. Jersey and RESTEasy seem to invoke the interceptor, but CXF does not.
Any thoughts?
Christian
_______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________ jaxrs-dev mailing list jaxrs-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
|
