users@jersey.java.net

Re: [Jersey] Configuration of default Entity Providers

From: Alex Treppass <alextreppass_at_googlemail.com>
Date: Wed, 26 May 2010 10:11:59 +0100

Posted issue #534: https://jersey.dev.java.net/issues/show_bug.cgi?id=534

<https://jersey.dev.java.net/issues/show_bug.cgi?id=534>I think I've
described the problem more succinctly in the issue report.

Alex
<https://jersey.dev.java.net/issues/show_bug.cgi?id=534>
On Wed, May 26, 2010 at 9:31 AM, Alex Treppass
<alextreppass_at_googlemail.com>wrote:

> Sure, I'll raise configuration of default registered providers as an
> improvement issue.
>
> > To work around the issue why don't you declare the media type you require
> in your application code?
>
> We don't want to hard-bake the return types into the server at compile
> time. Our use of Jersey revolves around hot-swapping return types at runtime
> by plugging in and offering different MessageBodyWriter instances, so that
> clients can use a particular method in our Web Service (i.e. search) and
> request results in a particular format (xml, json, etc), as well as develop
> their own MessageBodyWriters. This seems possible, but very fragile at the
> moment.
>
> To what extent is the ability for the JSR311 implementation to be
> runtime-configurable envisaged, moving forward?
>
> Regards,
>
> On Tue, May 25, 2010 at 5:40 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>> Hi Alex,
>>
>> To work around the issue why don't you declare the media type you require
>> in your application code?
>>
>> @Path("things")
>> public class ManageThings
>> {
>> @GET
>> @Path("{thingID}")
>> @Produces("application/xml") // Since you want to produce
>> "application/xml"
>> public Response IGetThing(@PathParam("thingID") int thingID)
>> {
>> if (thingID == 1 || thingID == 2)
>> {
>> return Response.ok(new Thing(thingID)).build();
>> }
>> return Response.noContent().build();
>> }
>> }
>>
>> If you do not declare @Produces then the default is */* so the most
>> acceptable and most compatible media type will be selected from that in the
>> accept header and the registered writers compatible with Java type.
>>
>> Can you log an issue with respect to sub-setting the default registered
>> readers/writers?
>>
>> Thanks,
>> Paul.
>>
>> On May 25, 2010, at 6:09 PM, Alex Treppass wrote:
>>
>> I've attached a testcase demonstrating this.
>>
>> Entity provider classes we've had to remove from the
>> META-INF\services\MessageBodyWriter file in jersey-core jar file:
>> package com.sun.jersey.core.impl.provider.entity;
>> XMLJAXBElementProvider.General
>> XMLListElementProvider.General
>> XMLRootElementProvider.General
>> XMLRootElementProvider.General
>>
>> With these classes left in, if one of them declares it can
>> produce application/xaml+xml (in the code it declares to be able to produce
>> anything +xml) then it'll mark our response with an incorrect return type -
>> in this case application/xaml+xml when it should just be application/xml.
>>
>> From the log files for a request from IE 7.0.5730.13:
>>
>> INFO: 1 * Server in-bound request
>> 1 > GET http://localhost/REST/things/1
>> 1 > accept-encoding: gzip, deflate
>> 1 > connection: Keep-Alive
>> 1 > host: localhost
>> 1 > accept-language: en-gb
>> 1 > user-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET
>> CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)
>> 1 > ua-cpu: x86
>> 1 > accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
>> application/x-shockwave-flash, application/vnd.ms-excel,
>> application/vnd.ms-powerpoint, application/msword,
>> application/x-ms-application, application/x-ms-xbap,
>> application/vnd.ms-xpsdocument, application/xaml+xml, */*
>> 1 >
>>
>> 25-May-2010 16:53:19
>> com.sun.jersey.api.container.filter.LoggingFilter$Adapter finish
>> INFO: 1 * Server out-bound response
>> 1 < 200
>> 1 < Content-Type: application/xaml+xml
>> 1 <
>> <?xml version="1.0" encoding="UTF-8"
>> standalone="yes"?><thing><id>1</id></thing>
>>
>> The xml being returned is valid, as our POJOs are just JAXB annotated
>> classes, but the incorrect content-type causes IE to *hard crash* each time.
>>
>> Alex
>>
>> On Tue, May 25, 2010 at 3:43 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>>
>>> HI Alex,
>>>
>>> Can you share some code so i understand better the issue?
>>>
>>> On May 25, 2010, at 4:17 PM, Alex Treppass wrote:
>>>
>>> Jersey should enable the configuration of the default Entity Providers.
>>>
>>> We have recently been having issues with the various XML*.General
>>> classes.
>>>
>>>
>>> What entity provider classes are you specifically referring to?
>>>
>>>
>>> These classes claim to be able to correctly process application/atom+xml
>>> and application/xaml+xml despite the fact that they clearly can’t.
>>>
>>>
>>> What Java types are you using to produce or consume those media types?
>>>
>>> Paul.
>>>
>>> In particular, IE has the really nasty trait of producing an accept
>>> header that may include application/xaml+xml and */* but does not include
>>> text/html. This means that when IE connects to a Jersey web service the
>>> specific application/xaml+xml takes priority over the generic */* and the
>>> web server “produces” application/xaml+xml.
>>>
>>> Xaml is a special format that has an external DTD. The generic class in
>>> Jersey does not have the capability to create xml to that schema and should
>>> not be announcing that it can. The faulty application/xaml+xml causes IE to
>>> crash hard.
>>>
>>> I haven’t yet tested what various RSS readers do when confronted with
>>> malformed feeds – but I doubt that it’s pretty.
>>>
>>> We have modified the current Jersey jars to prevent the XML*.General
>>> Entity Providers from being loaded. This is not maintainable. If the General
>>> Entity Providers are considered essential to the Jersey implementation of
>>> JSR311 then we would like the ability to configure the Entity Providers at
>>> runtime.
>>>
>>> While the specification states that “An implementation MUST include
>>> pre-packaged MessageBodyReader and MessageBodyWriter implementations for the
>>> following Java and media type combinations”, it does not say that an
>>> instance of an implementation must load these MessageBodyReader and
>>> MessageBodyWriter objects at runtime.
>>>
>>> Regards,
>>>
>>>
>>>
>> <testcase.zip>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>