Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Clarification regarding ReaderInterceptor
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


On Tue, Sep 11, 2018 at 8:13 AM Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:
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

On Sep 11, 2018, at 1:22 AM, Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:

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@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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev

Back to the top