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
>