On Jan 21, 2009, at 7:37 PM, amsmota_at_gmail.com wrote:
> Many thanks for that. I was about to implement that myself, but I
> ended using
>
> HttpHeaderFactory.createAcceptMediaType(...)
>
> with some twists.
Are you aware of:
Request.selectVariant
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/Request.html
#selectVariant(java.util.List)
?
> I really wanted to put some more Jersey stuff on my application,
> specially those nice "injected interfaces" (I don't know if I like
> the concept, though) and following your recommendation in [1], but
> time is against me... Specifically, I eventually will want to use
> some of the web/servlet stuff but in other "connectors" like JMS and
> IMAP (the ones I implemented already) and others... Do you think
> that makes sense?
>
IIRC i think i suggested if you want to use more Jersey stuff that you
would need to write your own containers using the container SPI and
mapping the JMS/IMAP request/responses to Jersey equivalent requests
and responses. This will allow you to reuse all of the Jersey/JAX-RS
infrastructure. Note that i would not worry about the fact that you
need to convert say an IMAP request to a Jersey request as it is a
mapping that you define. My guess is if you are doing it another way
you are already doing such a mapping but perhaps implicitly and
perhaps spread out over code.
It is really very easy to create a new container and the mapping is
very simple:
Request:
- a base URI
- a request URI
- zero or more headers
- an input stream
Response
- status
- zero or more headers
- an output stream
> Cheers.
>
> [1] https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=3286
>
>
> P.S. I noticed that I was answering directly to you, so I'm putting
> this back in the list. Sorry for that.
>
If you write say an IMAP or JMS container i would be very interested
to know if you are willing to contribute such containers back to the
Jersey project :-)
No problem.
Paul.
>
>
> On Jan 21, 2009 11:54am, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> >
> >
> > On Jan 21, 2009, at 12:41 PM, amsmota_at_gmail.com wrote:
> >
> >
> >
> >
> > Thanks for your quick (as usual) reply... However...
> >
> >
> >
> > On Jan 21, 2009 11:20am, Paul Sandoz Paul.Sandoz_at_sun.com> wrote:
> >
> > >
> >
> > > On Jan 21, 2009, at 12:10 PM, amsmota_at_gmail.com wrote:
> >
> > >
> >
> > > Also, does Jersey considers the quality values when matching
> mime types?
> >
> > >
> >
> > > Yes, quality values of media types in the accept header but not
> currently of media types in the @Produces.
> >
> >
> >
> > How does Jersey does that? Because I'm using the MediaType
> implementation to do that
> >
> >
> >
> >
> >
> >
> > It only looks at quality parameters of media types *in the Accept
> header*. The list of media types in the accept header is ordered
> according to the quality parameter (an absence means a quality of
> 1.0).
> >
> >
> >
> > See the method:
> >
> >
> >
> > javax.ws.rs.core.HttpHeaders.getAcceptableMediaTypes()
> >
> > https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/core/HttpHeaders.html
> #getAcceptableMediaTypes()
> >
> >
> >
> > The JAX-RS spec defines the matching algorithm:
> >
> >
> >
> > https://jsr311.dev.java.net/nonav/releases/1.0/spec/
> spec3.html#x3-360003.7.2
> >
> >
> >
> > See part 3.
> >
> >
> >
> >
> >
> >
> > if(anotherType.isCompatible(type))
> >
> >
> >
> >
> >
> >
> > Compatibility only looks at the type and subtype and wildcards.
> >
> >
> >
> >
> >
> >
> > but nowhere there is the quality present. And it seems it does
> only a simple string comparison to match the types.
> >
> >
> >
> > So, given this situation
> >
> >
> >
> > Accept: application/octet-stream
> >
> >
> >
> > @Produces("text/html")
> >
> > produceHtml()
> >
> >
> >
> > @Produces("application/pdf")
> >
> > producePdf()
> >
> >
> >
> > shouldn't the producePdf be matched?
> >
> >
> >
> >
> >
> >
> > Not for the browser based Accept header you presented in the
> previous email.
> >
> >
> >
> > Yes for the curl example.
> >
> >
> >
> > Paul.
> >