Awesome stuff Paul, many thanks! Taking it for a spin now...
2009/1/27 Paul Sandoz <Paul.Sandoz_at_sun.com>:
> Hi James,
>
> I think you captured things accurately.
>
> I have just committed a fix to the trunk, it will take an hour or two to
> wind up as a 1.0.2-SNAPSHOT (assuming no networking issues we have for
> deployment to the repo which can often occur).
>
> So you should now be able to use @ImplicitProduces (TODO JavaDoc) on a
> resource and the media types declared will be the most acceptable if they
> are declared by the client. And, those media types will be supported
> correctly for conneg with explicitly declared methods.
>
> Note that i have not applied the patch to the Bookstore app cause of issues
> with embedded GF and we need to switch over to Jetty.
>
> Paul.
>
>
> On Jan 27, 2009, at 6:11 PM, James Strachan wrote:
>
>> I tweeted a while ago during a moment of frustration getting implicit
>> views to work with a resource bean that also returned XML & JSON
>> http://twitter.com/jstrachan/statuses/1120925036
>>
>> which led to Paul kindly responding to me which led to a bit of a long
>> conversation which we thought was better we brought over here to see
>> what others thought.
>>
>> So here's a quick summary of a rather long conversation...
>>
>> I kinda touched on the issue in my rather long rambling blog post
>>
>> http://macstrac.blogspot.com/2009/01/jax-rs-as-one-web-framework-to-rule.html
>>
>> and raised an issue around this area...
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=187
>>
>>
>> Basically the issue boils down to the JAX-RS specification favouring
>> more specific paths to implicit or regex ones and there being no way
>> to prefer one representation over another on the server side; if you
>> have implicit views or explicit views defined like this...
>>
>> @GET
>> @Path("{view}")
>> @Produces({MediaType.TEXT_HTML})
>> public Viewable genericView(@PathParam("view") String view) {
>> return new Viewable(view, this);
>> }
>>
>> and some XML/JSON methods such as this on the same resource...
>>
>> @GET
>> @Path("foo")
>> @Produces({"text/xml", "application/xml", "application/json"})
>> public SomeDTO getSomeDTO() {
>> ...
>> }
>>
>> then typically you'll want your web application to return HTML by
>> default unless XML/JSON is the only option preferred - whereas the
>> exact opposite happens; XML/JSON is usually always returned to web
>> browsers.
>>
>> Its even worse with Apple's Safari which has an accept header of this...
>>
>>
>> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>>
>> which tends to favour text/xml anyway (despite it only rendering XML
>> as plain text! :).
>>
>>
>> So there's a need to be able to annotate a resource to kinda say 'use
>> implicit views for this resource in priority to other representations'
>> to be able to do what most web framework users would expect (returning
>> HTML by default to web browsers).
>>
>> Paul suggested we use an annotation like
>> @ImplicitProvides("text/html") so we can annotate explicitly that
>> implicit views be used and to use them in preference to other
>> representations if there is a wide ranging accept header (such as for
>> web browsers). Being able to specify qualities on MIME types can also
>> help this...
>>
>> https://jsr311.dev.java.net/issues/show_bug.cgi?id=65
>> https://jsr311.dev.java.net/issues/show_bug.cgi?id=46
>>
>> The aim of this is to let Jersey with implicit/explicit views behave
>> kinda like a normal web framework, unless folks ask for only a
>> specific kind of representation (say XML or JSON). As a small stepping
>> stone I've submitted a couple of patches to the bookstore application
>> to show how such a HTML + XML/JSON application could look with
>> implicit views...
>>
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=189
>> https://jersey.dev.java.net/issues/show_bug.cgi?id=190
>>
>> (the tests fail currently as it returns XML instead of HTML to
>> demonstrate the issue we're trying to solve :)
>>
>> Paul's been looking at a way to implement @ImplicitProduces in a
>> simple way to do accept filter modification in lieu of more wider
>> ranging changes to the JAX-RS specification to support the
>> mimeType;q=someNumber type notation on media types to denote
>> priority/quality and using that to sort the possible representations
>> that can be returned from a JAX-RS request ahead of the current rules
>> of the path length etc.
>>
>> I think that gives a rough overview; Paul did I miss anything (other
>> than lots of rambling from me :)?
>>
>> Anyone else hit similar issues or have any further thoughts on this?
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://fusesource.com/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/