Yeah, but ContainerRequest, ContainerResponse need a |WebApplication
<
https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/container/WebApplication.html>
instance, that we don't have. And it seems, at least from the name, that
is HTTP-coupled.
We have our own Request class, that is just a wrapper for a bunch of
things, and a Response that is a javax.ws.rs.core.Response.
Other than that, we are doing what you describe, where possible using
Jersey otherwise with our own code.
BTW, how about the parameter binding? How do you do it? Directly from
the HTTP request? If so, there's another coupling...
|
Paul Sandoz wrote:
> On Oct 5, 2009, at 11:59 AM, António Mota wrote:
>
>> In some week or two I'll like to have more information on that.
>> However, let me make some considerations:
>>
>> - IMO, the HTTP stuff should be totally decoupled from the REST stuff.
>> - Without this decoupling, I'm afraid the use of
>> ContainerRequest/ContainerResponse will just be tunnelling the other
>> protocols over HTTP
>
> To be clear it is not tunneling protocols over the HTTP protocol. An
> FTP or SMTP request would not be converted to a physical HTTP request
> on the wire. That is very different from utilizing Jersey's container
> support.
>
> It is mapping of the Jersey abstractions of request and response. I
> strongly suspect you can map FTP/IMAP things at the level of Jersey
> containers. IIRC ESB type integrations of Jersey at the
> container-level (MuleSource, OpenESB) may be able to do just that.
>
> IIUC you are also mapping JAX-RS/Jersey abstractions, but at a
> different level using Jersey's abstract model and
> matching/dispatching. For example if you support @Path you must be
> supplying URIs or paths. Like-wise for @Produces or @Consumes and
> message body readers and writers there needs to be information about
> media types (if they can be appropriately utilized in FTP and IMAP).
>
> A Jersey container request has the following:
>
> https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/container/ContainerRequest.html
>
>
> 1) base URI;
>
> 2) request URI;
>
> 3) a method name
>
> 4) a set of request name/value pairs (request headers)
>
> 5) a request entity input stream
>
> https://jersey.dev.java.net/nonav/apidocs/1.1.2-ea/jersey/com/sun/jersey/spi/container/ContainerResponse.html
>
>
> A Jersey container response has the following:
>
> 6) a response status code
>
> 7) a set of response name value paris (response headers)
>
> 8) a response entity object
>
> The above is fairly general.
>
> For Jersey to function correctly it does require the mapping of some
> information to/from HTTP-based semantics. But this is not tunneling,
> it is mapping :-)
>
> For requests Jersey may require some values within the request and
> response to utilize HTTP semantics e.g. Content-Type, Accept headers
> if you want to the @Produces/Consumes annotations to work correctly.
>
> For responses you may require to map HTTP status codes and certain
> header values (e.g. Content-Type).
>
> The set information required to be mapped for Jersey resource classes
> to function correctly is actually rather small.
>
> Paul.
>
>
>> - Just FYI (Paul, Cameron) at the moment we have 4 connectors, HTTP,
>> IMAP, IntraVM and JMS. I think we had a JCR one but I can't find it
>> so we probably drop it.
>> - We're planning to drop the IntraVM in favor of a IntraJMS one, so
>> we'll have 3. But it's fairly simple creating new ones.
>> - All the connectors extend a AbstractConnector, with the exception
>> of the HTTP one because we have all the Web Spring stuff working on
>> that one, so we are using composition and delegation to "simulate"
>> multiple inheritance. All of then implement a Connector interface.
>> - It's those connectors, individually and independently, that
>> connects to our Resources, where the Jersey annotated interfaces (the
>> Services) are injected, introspected, methods matched, params bounded
>> (delegated), content negociated, service methods called and responses
>> sent back to the connectors. So, there is no tunnelling of one
>> protocol over other.
>> - We also have a bunch of UserAgents implemented, but I didn't
>> develop those.
>> - We had all this integrated with Spring Integration, but at certain
>> point we had to drop it. However, to implement it again it's just a
>> matter of configuration.
>>
>> That's it, a overview of what we've done based on Jersey.
>>
>>
>> Paul Sandoz wrote:
>>> Hi Cameron, Antonio,
>>>
>>> It may be possible to plug in other protocols using the Jersey
>>> container APIs.
>>>
>>> For example, one might be able to plug in support for FTP or SMTP by
>>> implementing such a container. One would need to map the
>>> request/response information of the protocol to the Jersey
>>> ContainerRequest/ContainerResponse classes. I can provide more
>>> details if required.
>>>
>>> Note that from the perspective of the application the @Path contains
>>> no scheme/host information.
>>>
>>> Of course certain protocols may break some of the REST constraints.
>>> For example FTP is a stateful protocol so it breaks the stateless
>>> constraint.
>>>
>>> Paul.
>>>
>>> On Oct 5, 2009, at 9:52 AM, Cameron Jones wrote:
>>>
>>>> Yes, i think jersey to support other protocols would be really
>>>> interesting. The most important aspect of jersey & jax-rs for me is
>>>> in the URI dispatching which is a great implementation of regex &
>>>> annotations. Since URIs reference all protocols it seems to make
>>>> sense that it could be extended to support this. i don't know
>>>> whether this would be a jax-rs spec enhancement or a
>>>> jersey-specific implementation detail like the viewables but i
>>>> would be interested in working on it as it aligns wit what i am doing.
>>>>
>>>> cam
>>>>
>>>>
>>>> On 05/10/2009, at 7:39 AM, António Mota wrote:
>>>>
>>>>> Be aware of what Paul said, the IntrospectionModeller is not part
>>>>> of the public API so if you use it you have to be prepared for a
>>>>> eventual break in the future.
>>>>>
>>>>> I don't have any links or pointers, I had to do everything just by
>>>>> looking at the code and do things myself (with the help of this
>>>>> list, I suggest you look at the threads I initiated, they are
>>>>> probably about that).
>>>>>
>>>>> I think it will be very interesting if Jersey at some point
>>>>> decided to support other protocols (or at least to decouple the
>>>>> HTTP stuff from the REST stuff), but that is probably a too much
>>>>> big refactoring of their code by now. If they decide to do it I
>>>>> would be happy to contribute as I have a clear idea of what I did
>>>>> to implement that decoupling.
>>>>>
>>>>> If you have some specific questions in the future feel free to
>>>>> ask, preferably on the list to go to the archives, maybe it will
>>>>> be useful to other people as well.
>>>>>
>>>>> Cheers.
>>>>>
>>>>>
>>>>> Cameron Jones wrote:
>>>>>> Thanks António! That's just what i was looking for!
>>>>>>
>>>>>> I think i might end up running into some of the same issues that
>>>>>> you have as i have to start supporting FTP and other protocols soon.
>>>>>>
>>>>>> If you have any links or pointers they would be most appreciated!
>>>>>>
>>>>>> Thanks,
>>>>>> cam
>>>>>>
>>>>>>
>>>>>> On 02/10/2009, at 10:59 PM, António Mota wrote:
>>>>>>
>>>>>>> Hmm, that is strange, because I'm actually using *a lot* of the
>>>>>>> AbstractResource capabilities, accessing it by using
>>>>>>>
>>>>>>> this.abstractResource =
>>>>>>> IntrospectionModeller.createResource(this.componentInterface);
>>>>>>>
>>>>>>> ("this" is my ResourceImpl)
>>>>>>>
>>>>>>> I must even say that practically all our work with Jersey is
>>>>>>> based on this...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Paul Sandoz wrote:
>>>>>>>> Hi Cameron,
>>>>>>>>
>>>>>>>> Can you describe a bit about what you would like to do?
>>>>>>>>
>>>>>>>> On Oct 2, 2009, at 12:19 PM, Cameron Jones wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm not very familiar with annotations processing or the
>>>>>>>>> jersey implementation, is there an easy way to access a
>>>>>>>>> resource's annotations?
>>>>>>>>>
>>>>>>>>> The AbstractResource class has the kind of methods i am
>>>>>>>>> looking for but is it accessible to resources?
>>>>>>>>>
>>>>>>>>
>>>>>>>> There is currently no publicly available functionality to
>>>>>>>> obtain the AbstractResource from a resource class. Such
>>>>>>>> functionality would be very easy to expose. But it would help
>>>>>>>> if i can understand what you use-case is.
>>>>>>>>
>>>>>>>> Paul.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>