[Resteasy-users] Problem with multipart/mixed when parts have custom mime type
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);
ListInputPart 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=60135991iu=/4140/ostg.clktrk
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
[Resteasy-users] Announcing Arquillian REST extension.
Hi RESTEasy users, We would like to inform you that the JBoss Arquillian universe just extended with completly new extension that was designed to ease the testing of JAX-RS based web services: http://arquillian.org/blog/2013/10/28/arquillian-extension-rest-1-0-0-Alpha1/ One of of it's unique features is the integration with Arquillian Warp that does allow to intercept the state of the service running and verify it in a test that is being executed in the application container. We were hoping that you could give a try and give us as much feedback as possible. We also welcome any contributions to the newly developed extension. Thanks, Jakub Narloch -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Announcing Arquillian REST extension.
Bill, From the looks of it, the framework is actually leveraging your client framework.. https://github.com/arquillian/arquillian-extension-rest/blob/master/rest-client/impl/impl-3x/src/main/java/org/jboss/arquillian/extension/rest/client/RestEnricher.java#L94 Anyways, the use cases are many. Basically, a test can now have a handle injected to it that points to the REST API, no need to figure out the URL. On Mon, Oct 28, 2013 at 6:10 PM, Bill Burke bbu...@redhat.com wrote: Have you seen our proxy extension? (This exists in 2.3.x too) http://docs.jboss.org/resteasy/docs/3.0.4.Final/userguide/html/RESTEasy_Client_Framework.html#d4e2101 I guess I just don't understand what problem you are trying to solve with this extension. On 10/28/2013 5:56 PM, Jakub Narloch wrote: Hi RESTEasy users, We would like to inform you that the JBoss Arquillian universe just extended with completly new extension that was designed to ease the testing of JAX-RS based web services: http://arquillian.org/blog/2013/10/28/arquillian-extension-rest-1-0-0-Alpha1/ One of of it's unique features is the integration with Arquillian Warp that does allow to intercept the state of the service running and verify it in a test that is being executed in the application container. We were hoping that you could give a try and give us as much feedback as possible. We also welcome any contributions to the newly developed extension. Thanks, Jakub Narloch -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
