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
>