On Mar 3, 2010, at 11:01 PM, António Mota wrote:
> 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?
>
No. The ServletContainer will add injectable items for injecting
servlet specific stuff but that is independent of WebApplication and
WebApplicationImpl.
One could rename WebApplication to JerseyApplication, HttpContext to
JerseyContext etc.
> 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?
>
The conneg semantics are specific to HTTP headers as specified by HTTP
1.1.
That is a mapping issue. So if you want to support @Consumes/_at_Produces
for other protocols the container you implement needs to map it's
protocol request information appropriately to Accept and/or Content-
Type headers.
> 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 :)
>
OK :-)
> Thanks again for your ever prompt replies.
Np,
Paul.
> _________________________________________________
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>