On Nov 18, 2008, at 5:04 PM, António Mota wrote:
> 2008/11/18 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>
>> Still confused. Why do you want to do that? what is the higher
>> level goal?
>> Are you writing your own support for dispatching HTTP requests to
>> resource
>> classes? if do you are doing a lot of work that Jersey already does
>> for you.
>
>> I suspect you want to control dispatching to Jersey is that correct?
>
> Yes, basically I want to match a Request (URI+Verb+Accepts) to the
> annotations (@Path at class level and @Path+_at_GET(or other
> Verb)+_at_ProduceMime at method level).
>
> I understand from what you just said that Jersey does just that, but
> the true is I didn't found any way to do it, unless from what I saw
> from the examples using Glassfish or the internal Grizzly
>
Yes, if you have a look at the ServletContainer code:
- there is some config stuff to create a ResourceConfig and
register resource classes.
- then a WebApplicaton is created.
- the Servlet.service method creates a ContainerRequest and
ContainerResponse and dispatches to WebApplication.
You should not have to do the mapping of requests to classes yourself.
I believe we can probably refactor the servlet functionality better to
make it more reusable, perhaps as a context listener?
>> The recommended approach is to use a servlet supplied by Jersey.
>> There are two, a basic one and a
>> spring-based one. Currently it is not easy to utilize your own
>> servlet and dispatch to Jersey when
>> appropriate, something we definitely need to improve on, perhaps
>> using a Servlet filter instead.
>
> Actually, "my" servlet is Spring Dispatcher Servlet dispatching to a
> extended AbstractCommandController where I "talk" with my Resource
> that in turns choose the class/method to be invokes, pass that back to
> the controller tat invokes it and receives the results (with SI in the
> middle).
>
> So maybe it's not that diferent if I use the Jersey Spring Servlet,
> I'll try.
>
Perhaps :-)
> Also, I'll try to upgrade to 1.0.
>
OK.
>> I see. I think you may be doing something new that is a little
>> different
>> from the use-cases we currently support. I am not sure because i
>> don't
>> really understand what a Spring Integration Gateway is.
>
> SI gateway basically is just a wrapper that defines two endpoints and
> the channels in between and wraps (with AOP) the injected interface so
> any call will be rerouted thru the messaging infrastructure.
>
>> But i am guessing
>> you are writing a general proxy to support N number of interfaces.
>> And one
>> could register interfaces as root resource classes and then defer
>> to spring
>> to get the instance of the interface to invoke methods.
>
> Yep, I couldn't describe better myself...
>
>> I would be happy to
>> work with you to support your use-case for the latest Jersey code
>> but it is
>> hard to do for 0.8.
>
> Yes of course, I'll try to upgrade to 1.0, althougth I'm a bit
> concerned about that "matrix" thing that is working right now and
> maybe will brake.
>
I think it will. There is a Jersey specific solution to work around
that, which is to define your own injectable and annotation to get
access to all the matrix params as a map. I can present code for that
this week if you wish.
> Nevertheless I'll let you know the outcome. And once again thanks for
> your precious work and help.
>
No problem,
Paul.