On Nov 18, 2008, at 12:56 PM, António Mota wrote:
> Hi, thanks for your quick reply.
>
> 1) If I understood correctly, it will be responsibility of the AS to
> somehow inject some instance of UriInfo into the application (or at
> least some kind of container like Spring), so that will only work with
> a AS/Container that is JAX-RS aware, or am I wrong? I tried to inject
> it with Spring, but of course complains that UriInfo is not a class.
>
No, it is the responsibility of the JAX-RS implementation, and it
would depend on how you implement it. Jersey implements its own
limited IoC support so that it can work independently of any IoC
container. It is also independent of the HTTP container so it works
with an app server but also works using Grizzly for an embedded mode.
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).
> 2) We're using Jersey 0.8, and planning to upgrade to 1.0 only if
> necessary cause we're close to our deadline and don't want to risk
> changes.
OK.
>
>
> But I don't understand exactly your explanation. What I'm doing
> basically is looping to the abstractResource.getSubResourceMethods(),
> get the UriPath of each and using a UriTemplate to match it, something
> like
>
> for (AbstractSubResourceMethod subMethod :
> abstractResource.getSubResourceMethods()) {
> uriPath = subMethod.getUriPath().getValue();
> uriTemplate = new UriTemplateRS(uriPath);
> if (uriTemplate.matchExact(uri, map)) {
> //do some more checks here
> return subMethod;
> }
> }
>
Why are you doing that? is that for testing purposes?
> and the order they appear is precisely the contrary of what the spec
> says. Nevertheless, the problem still arises because a URI to be
> matched to the second path will be matched by the first anyhow.
>
The order of the sub resource methods will not be returned in the
matching order, it will be returned in declaration order (which is
undefined in terms of Java reflection). The sorting according to paths
happens else where, and needs to take both sub-resource locators and
sub-resource methods into account.
> Is there a more "jersyan" way to do this?
>
I am not sure, first i need to know a bit more about why you are using
the abstract model.
> 3) Yes, I'm using Matrix params. First, let me tell you that I
> searched the net for a good explanation of Matrix params and the only
> good source of information I've found were your answers in a thread on
> this mailing list archives. Thank you for that.
>
> Now, from what you just said, that is starnge because I'm getting
> exactly what I want, for instance, for
>
> @GET
> @Path("/data/query/{queryname}")
> Object getQuery(@PathParam("queryname")String queryName,
> @MatrixParam("queryparams")Map<String, String> params);
>
> and
>
> /data/query/countriesBy2LetterCodeOrByNumCode;
> 2letterCode=PT;numCode=620
>
> in my params Map I get the two entries.
>
I am surprised that works. The value declared in the @MatrixParam
should be associated with a matrix parameter, such as "2letterCode" or
"numCode". I think it is because you are depending on Jersey 0.8 which
is rather old and was evolving according to the JAX-RS specification.
> 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?
Note that you can also inject onto fields (if resource class is
request-scoped) for such request-based parameters.
>
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.
Paul.
> Once again, thanks for your input.
>
>
>
> 2008/11/18 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>>
>> On Nov 18, 2008, at 11:43 AM, António Mota wrote:
>>
>>> Hello:
>>>
>>> I'm new in here, I'm developing a REST infrastructure for our
>>> internal
>>> applications based basically on Spring Integration. I only
>>> "discovered" Jersey in the middle of the project and started using
>>> parts of it, so now my project is a mix of SI and Jersey. Basically,
>>> SI for the communication and server-side handling and Jersey for the
>>> connectors/resources side.
>>>
>>> So in this context I have some questions:
>>>
>>> 1) It seems that Jersey is tightly coupled with Glassfish, in a way
>>> hat is only partially usable on other platforms, like in my case
>>> JBoss. For instance, UriInfo being a "injectable interface" will not
>>> work anywhere besides Glassfish, or am I wrong?
>>>
>>
>> The annotations and injection rules are specified by JAX-RS so it
>> should be
>> portable across JAX-RS implementations. Thus Jersey should work in
>> this
>> respect with any app server.
>>
>>
>>> 2) I'm relying heavily on the Jersey annotations
>>
>> Those are JAX-RS annotations, so again they are portable.
>>
>>
>>> and the
>>> AbtractResource and SubResources to match the templates with my
>>> resource's methods. I have a problem with this situation:
>>>
>>> @GET
>>> @Path("/data/{entity}/{key}")
>>> Object read(@PathParam("entity")String entity,
>>> @PathParam("key")String key);
>>>
>>> @GET
>>> @Path("/data/query/{queryname}")
>>> Object getQuery(@PathParam("queryname")String queryName,
>>> @MatrixParam("queryparams")Map<String, String> params);
>>>
>>>
>>> From what I saw until now, the same URI will always be matched by
>>> these two paths, is there any way to distinguish between a "fixed"
>>> part of the uri and a "variable" one?
>>>
>>
>> It should work, what version of Jersey have you tried?
>>
>> The spec states:
>>
>> Sort E using the number of literal characters in each member as the
>> primary
>> key (descending order), the number of
>> capturing groups as a secondary key (descending order) and the
>> number of
>> capturing groups with non-default regular
>> expressions (i.e. not '([^ /]+?)') as the tertiary key (descending
>> order).
>>
>> Thus the path template of "/data/query/{queryname}" will be sorted
>> before
>> "/data/{entity}/{key}" in terms of matching, because the former
>> contains
>> more literal characters than the latter. And therefore a path
>> consisting of
>> "<base>/data/query/params" will match the former template.
>>
>> I notice you want to use matrix params. A Map is not supported for
>> @MatrixParam [1]. If you want to get all matrix params associated
>> with a
>> path parameter you can do:
>>
>> @GET
>> @Path("/data/query/{queryname}")
>> Object getQuery(
>> @PathParam("queryname") PathSegment ps);
>>
>> Paul.
>>
>> [1] https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/MatrixParam.html
>>
>> ---------------------------------------------------------------------
>> 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
>