Well, when I have a little time I will see if I can inject the interfaces
in my connector/resource layer. Then, maybe in one month time after our
first release, I will try to integrate all that in a protocol-independet
layer, or as you refer to turn my connectors in request/response containers
as well (that now spans thru connector and resources).
And I will be very happy to contribute that back if it's worthy...
On Jan 22, 2009 9:35am, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> 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
>
>
>
>
>
> PS 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.
>
> >
>
>
>
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>