I remembered why I didn't proceed at that time investigating the
Jersey IoC. I saw that it was based on the WebApplication and my REST
infrastructure is to be protocol independent (as Roy Fielding itself
sugests in his dissertation).
So I have to have two different layers on the client-side, a
Connectors layer (which for now is only a HttpConnector) and a
Resources layer, that is responsible for finding and handle the right
resource to the connector to populate with the request and send to the
messaging infrastructure.
Take the example of a FileUpload service. Now I have that service as a resource:
@POST
@Path("/FileUpload")
void saveFile(@FormParam("filename")String name, @FormParam("file")
byte[] file);
and I have the HttpConnector that receives the request as a Multi-part
request, asks the ResourceFactory (let's call it that) to find and
instantiate the correct Resource, hand it back to the HttpConnector
that in turns populates the MessageBean and send it to the Messaging
infrastructure.
But I also want a Email connector, that receives a email with
"/FileUpload" as a Subject and a file as a attachment, and does the
same (asks the ResourceFactory, etc...).
So the finding of the correct resource cannot be the HttpConector (or
Servlet or whatever) but the Resource component that can have several
connectors connecting to him.
Any thoughts on this?
_______________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
António Manuel dos Santos Mota
mobile PT: +351919623568 (deprecated)
mobile IE: +353(0)877718363
mail: amsmota_at_gmail.com
skype: amsmota
msn: antoniomsmota_at_hotmail.com
linkedin: www.linkedin.com/in/amsmota
_______________________________________________
2008/11/18 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>