On Nov 18, 2008, at 2:34 PM, António Mota wrote:
> Here's some more thoughts.
>
>> Jersey works correctly in conjunction with Spring injecting JAX-RS/
>> Jersey
>> things on to spring managed beans (works correctly for singleton,
>> request.
>> prototype as well as Aop proxied).
>
> I found no way of doing that. I understand how Spring can inject it,
> but who is responsible for instantiate the classes, like for example
> the UriInfo? Do I have to use some kind of runtime environment
> specific of Jersey? I did saw examples instantiating a Servlet, that
> makes sense, but since I'm using my own Servlets, how can I do that?
>
I suspect you want to control dispatching to Jersey is that correct?
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.
It is hard for me to recommend what to do and help you because you are
utilizing version 0.8. I don't have the time/resources to go back in
detail to that version. Sorry :-(
If you were using 1.0 i would recommend instantiating directly the
Jersey Spring servlet and initiating it from within your own servlet,
then calling service as appropriate. Or perhaps taking the code, and
copying/modifying it.
>>> And I can't use PathSegment because I'm really only writing the
>>> service infrastructure, not the services themselves, and the
>>> services
>>> are supposed to be "business" methods from a interface extracted
>>> from
>>> a "business" class with just a bunch of rs annotations added, so I
>>> can't be bound to anything rs-specific.
>>>
>>
>> Do you mean to say that you have no control over the interfaces?
>
> Yep, I don't have control of interfaces. The annotated interfaces are
> injected in a Spring Integration Gateway that is handled by a generic
> Resource I've implemented (and so each interface "becomes a resource
> itself) , that is the responsible for matching http request to the
> correct method of the interface, with the corresponding implementation
> method being handled by the corresponding class that in turn was
> declared as a "endpoint" handler of SI.
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. 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. 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.
Paul.
>
>
>
>> The most important interface for RESTful Web services is HTTP. In
>> this
>> respect i don't think the interface/impl devision you is as
>> important as it
>> would be for the case when using RMI or SOAP. I don't understand
>> enough
>> about your use-case but i suspect you might be making it more
>> difficult for
>> yourself :-) You can easily create your own resource method that
>> transforms
>> information and then calls a business method.
>
> Our point here is that the services are completely unaware of the
> structure behind it, so a business class can be developed as normal,
> as if it were to be called locally every time. Then, only the public
> interface, after annotated with the corresponding paths, will be
> accessed remotely thru the rest layer.
>
> If i was to begin now, and knowing what I know now, it was better to
> start with Jersey and then integrate Spring Integration below it, but
> I did the opposite, I started with SI and integrated Jersey
> afterwards. And there is no tine to go back. As usual.......
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>