On Nov 20, 2008, at 10:46 AM, António Mota wrote:
> 2008/11/19 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>
>> The REST style is independent of protocol but the architecture you
>> apply the
>> style does not have to be. JAX-RS makes no attempts to be protocol
>> independent (but see later). Being protocol independent is an
>> architectural
>> decision you should make based on your requirements.
>
> Yes, of course, it was indeed our requirements that lead us to opt for
> a protocol-independent infrastructure based on messaging. We have to
> support al least 3 kinds of protocols, HTTP/S, IMAP/PO3 and JMS.
>
>> I recommend you support two different Jersey-based containers:
>>
>> 1) Using HTTP; and
>>
>> 2) Using SMTP and mapping the SMTP request/response to Jersey
>> ContainerRequest and ContainerResponse
>> that can then be passed to WebApplication.handle.
>
> Since we opted to be protocol-independent I think our approach of
> keeping two separate layers on the "client side", Connectors and
> Resources, is justified. And thus being the Resource layer the
> responsible to supply the connector(s) with the appropriate resource
> instance for a particular path/verb/mimeType.
>
> So I just made some changes to my Resource layer to correctly order
> the methods (AbstractSubResourceMethod) following the spec, for what I
> just used your UriTemplate.COMPARATOR.
>
OK. I still don't understand all your requirements and of course your
time constraints but my guess is you are probably doing much more work
than necessary, if you plugin at the request/response abstraction it
will most likely make you life much easier as you are really
duplicating much support that Jersey already provides.
IMHO it does not matter if the request/response abstraction is termed
in HTTP as long as you can map correctly, which think should be
possible since the request/response abstraction is really the following:
- request: URI, headers , request entity
- response: status, headers, response entity
> BTW, I did upgraded to Jersey 1.0 without problems,
Great.
> and strangely the
> question with the Matrix param didn't occur, I still receive all my
> params as a Map. That's strange in light of what you said and what
> the docs say. I'll have to take a closer look to that,
>
OK. Perhaps it is because of the way you are integrating?
>> A WebApplication instance created can be shared between the two. It
>> is quite
>> easy to support containers, for example look at MuleSource [1]. My
>> guess is
>> the mapping from an SMTP request to a ContainerRequest should be
>> rather
>> simple for what you require.
>
> When we first start discussing our REST architecture we had a very
> heated debate between using a ESB or not. My boss had the opinion of
> using Mule and I had more or less followed the opinion of Steve
> Vinoski in his much debated blog post "The ESB question".
>
:-) i thought so.
> We finally followed my (actually Steve's) opinion (and my boss is not
> known for changing his opinion lightly) and that's why we are using a
> "light" messaging infrastructure with "independent", "decoupled"
> connector/resource architecture that allows us to create and connect
> connectors as we go along.
>
> I should mention also that we looked at Restlet as a alternative but
> we decided for our "lighter" version.
>
OK.
>> You can also look at the code for the ServletContainer and the
>> GrizzlyContainer for other examples.
>
> I think we are now stable enough to go ahead (even more considering
> our time constraints) with our use of Jersey + Spring Integration.
>
> I would like to know more about the integration of Jersey with the
> Spring IoC because I'll really like to have access to those "injected
> interfaces" like the UriInfo that will save me lot's of work. I hope I
> can do it soon.
>
I personally would recommend utilizing 1.0.1-SNAPSHOT as the IoC
integration has been improved and we can make potential changes if we
find bugs. Note that we are releasing 1.0.1 on the 1st Dec. The
changes between 1.0 and 1.0.1 are most around package naming, mostly
with the implementation packages, and i have tried to limit the
disruption to the Jersey API/SPI area, the JAX-RS API of course
remains the same (with bug fixes to the implementation).
For an example of spring integration see:
https://jersey.dev.java.net/source/browse/*checkout*/jersey/trunk/jersey/contribs/spring/src/main/java/com/sun/jersey/spi/spring/container/SpringComponentProviderFactory.java?rev=1723
I suspect given your description that you might require something more
specialized.
> In the meantime, many thanks for your support, if I can contribute at
> least with some ideas I would be very happy to do it.
>
Thanks! If you have any ideas just say so :-)
Paul.