We found a strange problem receiving multipart/mixed when the parts
contained in the multipart message
have a custom mime type. Maybe we are using the API incorrectly, but the
framework?s behavior is not so
clear either.

Here?s the details:

We have a service method returning a multipart/mixed response as follows:

        @GET
        @Path("basic")
        @Produces({"multipart/mixed", "custom/type1", "custom/type2"})
        public Response getBasic() {
            MultipartOutput output = new MultipartOutput();
            output.addPart(new MyJaxbBeanType1(), new MediaType("custom",
"type1"));
            output.addPart(new MyJaxbBeanType1 (), new MediaType("custom",
"type2"));
            return Response.ok(output).build();
        }

The Client code looks like this:

        ResteasyProviderFactory factory =
ResteasyProviderFactory.getInstance();
        factory.registerProvider(MyTypesJAXBContextFinder.class);
        factory.registerProvider(MyTypesXmlRootElementProvider.class);

        ResteasyClientBuilder resteasyClientBuilder = new
ResteasyClientBuilder().providerFactory(factory);
        ResteasyClient client = resteasyClientBuilder.build();
        ResteasyWebTarget target = client.target(generateURL("/basic"));
        Invocation.Builder request = target.request();
        Response response = request.get(Response.class);

        MultipartInput input = response.readEntity(MultipartInput.class);

        //ResteasyProviderFactory.pushContext(Providers.class,
providerFactory);
        List<InputPart> parts = input.getParts();
        for (InputPart part : parts) {
            System.out.println(part.getBodyAsString()); //***
        }
        //ResteasyProviderFactory.popContextData(Providers.class);

This code fails on the client side with an exception (at the line marked
with "***") even though the  MessageBodyReaders for the
custom types seem to be registered properly in the factory, and
MultipartInputImpl references this factory. However, some
decorating "generic proxy" is called before the factory is called, and this
proxy checks with the factory's "contextData" first which Providers
implementation it is supposed to call (the exception is "LoggableFailure:
Unable to find contextual data of type: javax.ws.rs.ext.Providers",
thrown at ContextParameterInjector.java:54).

The Exception is thrown because "contextData" is null at this point.

The interesting parts are:

- response.readEntity(MultipartInput.class) checks "contextData" before
doing anything, pushes the factory as a Providers implementation
  to the context, processes the multipart data with MultipartReader, and
pops the provider from the stack again, so this part
  works perfectly.
- when commenting in the above line that pushes the provider factory to its
context things work perfectly; however, when instantiating
  a ResteasyProviderFactory instead of using the singleton provided by
ResteasyProviderFactory.getInstance() it does not work. This
  also begs the question whether multithreaded resteasy clients would work
(I guess they would because of this threadlocal stuff, but maybe
  there is some shared state somewhere that will prevent this from
working?).

Kind regards,

Robert Lauer.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Reply via email to