On Oct 5, 2009, at 4:23 PM, António Mota wrote:
> 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.
>
It is mostly by name only.
Most of the HTTP-logic is embedded in the matching rules relating to
creating resource classes and dispatching to resource methods, which
is based on processing certain header, specifically Accept and Content-
Type and setting response state in certain cases (e.g. if nothing is
acceptable or a message body writer cannot be found or a resource
cannot be found).
> 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.
>
OK. IIRC we spoke a while ago about this and you had some unique
requirements and time constraints. So i am not stating the Container
approach is right for you. I am just stating that i think it is
possible to use that to plug in other non-HTTP protocols.
> BTW, how about the parameter binding? How do you do it? Directly
> from the HTTP request? If so, there's another coupling...
That coupling is provided by a Jersey Container. You can provide a
different coupling with a different Container.
An HTTP container will create an instance of ContainerRequest copying
information from an HTTP request object supplied by the HTTP container
(e.g. in Servlet the HttpServletRequest) processing the HTTP request
received from the network.
However, this does not restrict another form of container obtaining
information by other means, mapping where appropriate, and creating an
instance of ContainerRequest.
When doing this at the level of the Jersey Container it is really a
mapping problem, and the information that needs to be mapped can be
minimal to get something functional.
Paul.
> |
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>