Hi Devon
Thanks for your update.
I'd like to clarify few details and comment a bit.
So you have two *root* resource classes, one implementing
// I've added @Path("/") because if it is not present on the root resource then it is
assumed to be "/"
@Path("/")
interface ADefaultResource {
@GET
@Path("{path:.+}/{tail}")
Response aKnownMethod();
}
and another one implementing
// I've added @Path("/") because if it is not present on the root resource then it is
assumed to be "/"
@Path("/")
interface AKnownResource {
@Path("/a/known/path/with/{variables}")
Response aKnownMethod();
}
so assuming it is the case, here some questions :
1. is it the case that requests like
/a/known/path/with/1/2
end up being handled by
AKnownResource.aKnownMethod();
while requests like
/a
will be dispatched to
ADefaultResource.aKnownMethod() ?
I'm not sure it should work given the way the selection algorithm is implemented, unless AKnownResource returns a ADefaultResource
as a subresource or vice versa ? Can you please clarify a bit how exactly AKnownResource and ADefaultResource are registered (as two
root resource classes or not, or are they related to each other)
Few more comments below
Hi Sergy,
Thank you very much for your response.
I did, eventually find a trick that worked. I changed my "default" service
to:
interface ADefaultResource {
@GET
@Path("{path:.+}/{tail}")
Response aKnownMethod();
}
It turns out that my "subresource" problem goes away as long as the last
matching chunk on the URI template is *not* a regex pattern. And the above
pattern ends up matching anything that is not otherwise matched to another
existing service. Obviously in this case, I am not actually using the path
variables in the service itself -- they are just a means to an end to get
the CXF dispatch service to find this method when appropriate.
The only way for @Path to use regular expressions is for a variable be
available so that the result of the match of a current
reg ex can be kept. But indeed, those path variables don't have to be used.
Perhaps it is not by design, but it turns out that the system does what i
had hoped: it matches the more specific services (even with variables) when
appropriate, and only falling back to the default method when no other
resource can handle it.
It's good it is working for you, but I don't understand yet why it is the case :-) Hopefully I'll have a clearer picture once you
provide some more info on the way AKnownResource and ADefaultResource are related/registered
------
Regarding the subresource error message: it is, in fact, a pipe character,
and not a slash. When I step into the code to see what is happening, I can
see that the path to be matched to a subresource is "|". This appears to
only happen when the last element of the URI Template is a regex pattern
that consumes the end of the URI prior to locating the subresource.
You originally were using @Path("{path:(.)+}") for default resource, right ? At
the moment you're using
@Path("{path:.+}/{tail}"). So as far as I understand, if it is a subresource locator method which is annotated with expression like
@Path("{path:(.)+}") then the runtime somehow picks up '|' as the next path segment to deal with...
Note that @GET/@POST don't seem to work when the patterns ends in regex -- that
is to say, using the @GET or @POST annotation does not stop the CXF dispatch
system from still trying to find a subresource matching "|".
Hmm... so if you have say
interface ADefaultResource {
@GET
@Path("{path:.+}")
Response aKnownMethod();
}
then after aKnownMethod() has been invoked, the system is still trying to locate a subresource, that is it is failing to recognize
that aKnownMethod() is not a subresource locator ?
I'm sure this is just an artifact of some bug related to the handling of URI
Templates which terminate in a regex variable.
You're right, there's a bug there indeed.
Andy - hope you're reading it. If you could test the following then it will be
appreciated a lot:
@Path("/")
public class Resource {
@Path("{var:.+}")
public Resource1 subresource() {
return this;
}
@GET
public String getString() {
return "1";
}
}
GET /bar
is apparently will cause JAXRS invoker to use a '|' character after subresource() has beein invoked, but it should be just '/' so
that getString() method is invoked.
thanks Sergey
Thank you very much for your time. Our team has been using CXF for several
months now, and we are very impressed!
Please let me know if I can answer any more questions about the behaviors I
am describing.
Thank you,
-Devon
