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