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
- 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
>