users@jersey.java.net

Re: [Jersey] Re: Multi protocol Jersey

From: António Mota <amsmota_at_gmail.com>
Date: Wed, 3 Mar 2010 22:01:10 +0000

I had to drop this again, sorry. Nevertheless, yes it makes all the
sense. However, and forgive me because I'm talking from the top of my
head from what I remember from some months ago, isn't those classes
(WebApplication, ...) dependent on the "injected interfaces" that are
themselves dependent on a web container?

Also, I specific remember having to write myself (albeit using lots of
Jersey stuff) all the code pertaining to resource discovery (or
matching is better said) and more problematic, the content negotiation
that it was very specific to HTTP, if I remember correctly. Was there
any change in recent releases?

Nevertheless these concerns are server-side, not at connector level,
and I think my boss manage to do it (rewrite our JMS connector to
support file uploading I think) more or less the way you describe,
with the exception of the output writer I think. I have to peek at his
code to see if everything look good :)

Thanks again for your ever prompt replies.
_________________________________________________

Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

http://card.ly/amsmota
_________________________________________________




On 1 March 2010 17:36, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
> Hi António,
>
> I recommend not getting too caught up in the name WebApplication.
>
> The Container and ContainerProvider classes can be reused to connect to a
> protocol other than HTTP and thus be able to reuse most of Jersey.
>
> The key part is for your container implementation to provide correct
> information to an instance of ContainerRequest and provide an appropriate
> implementation of ContainerResponseWriter.
>
> Basically this means w.r.t. the request mapping the following if present:
>
> - something to a base URI and a request URI
>
> - something to a map of request headers, including meaningfully mapping to
> some well known HTTP request
>  headers such as Content-Type or Accept.
>
> - something to a request body InputStream
>
> and mapping the response:
>
> - a status code to something
>
> - map of response headers, including meaningfully mapping from some well
> known HTTP response headers
>  such as Content-Type to something.
>
> - an output stream to something to write a response body
>
> As long as you can meaningfully map the request and response information as
> briefly described above i expect you can can support some degree of protocol
> independence for the protocols you mention. Of course you may need to be
> careful with the resource classes, for example if you utilize pre-condition
> support it may not be supported by all protocols.
>
> Does that make sense?
>
> Paul.
>
> On Mar 1, 2010, at 6:21 PM, António Mota wrote:
>
>> (I'm reposting this, it seems a strange formatting error ocurred....)
>>
>> Hello Paul and all:
>>
>> After some months I'm back to the list, as our work with REST and
>> Jersey is evolving. As I said earlier in this list I used Jersey until
>> now based on some "bits and pieces" and not the full stack, mostly
>> because since the beginning (around two years ago) we needed support
>> for a multi protocol architecture and at that time Jersey only
>> supported HTTP.
>>
>> However is of our interest to try to keep up with Jersey as it
>> evolves, and since we are thinking in doing some changes to our
>> connectors (FTP, JMS, IMAP and HTTP) we would like to "compatibilize"
>> then with the current status of Jersey. So Paul (I assume it's you who
>> knows about this), would you care to point me to the current status of
>> your implementation, following the lines of [1]?
>>
>> My boss told me something about 1.1.5 support for this by using
>> ContainerProvider / Container classes, but I would like to go back to
>> what we discuss on that thread... Specially, is all the work of
>> resource discovery, content-negociation, url-parsing and those things
>> that are protocol agnostic now decoupled from the HTTP stuff, like the
>> WebApplication or the Jersey ServletContainer and so?
>>
>> Thanks a million.
>>
>> [1] http://n2.nabble.com/AbstractResources-tp3754606p3767918.html
>> _________________________________________________
>>
>> Melhores cumprimentos / Beir beannacht / Best regards
>>
>> António Manuel dos Santos Mota
>>
>> http://card.ly/amsmota
>> _________________________________________________
>>
>>
>>
>>
>> 2010/3/1 António Mota <amsmota_at_gmail.com>:
>>>
>>> Hello Paul and all: After some months I'm back to the list, as our work
>>> with REST and Jersey is evolving. As I said earlier in this list I used
>>> Jersey until now based on some "bits and pieces" and not the full stack,
>>> mostly because since the beginning (around two years ago) we needed support
>>> for a multi protocol architecture and at that time Jersey only supported
>>> HTTP. However is of our interest to try to keep up with Jersey as it
>>> evolves, and since we are thinking in doing some changes to our connectors
>>> (FTP, JMS, IMAP and HTTP) we would like to "compatibilize" then with the
>>> current status of Jersey. So Paul (I assume it's you who knows about this),
>>> would you care to point me to the current status of your implementation,
>>> following the lines of [1]? My boss told me something about 1.1.5 support
>>> for this by using ContainerProvider / Container classes, but I would like to
>>> go back to what we discuss on that thread... Specially, is all the work of
>>> resource discovery, content-negociation, url-parsing and those things that
>>> are protocol agnostic now decoupled from the HTTP stuff, like the
>>> WebApplication or the Jersey ServletContainer and so? Thanks a million. [1]
>>> http://n2.nabble.com/AbstractResources-tp3754606p3767918.html
>>> _________________________________________________ Melhores cumprimentos /
>>> Beir beannacht / Best regards António Manuel dos Santos Mota
>>> http://card.ly/amsmota _________________________________________________
>>
>> ---------------------------------------------------------------------
>> 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
>
>