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