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,
>
>
>