cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Linus Kamb" <>
Subject RE: Is it possible to register a default resource?
Date Thu, 15 Oct 2009 09:13:05 GMT
This is great.

I can have

interface ServiceInterface {
  Response defaultMethod();

  Response serviceMethod();

And, it seems, everything but /a/correct/path will get shunted to

It can be further controlled by @Produces, and you can add required

I don't know if this was the original poster's question, and I'm sure I'm
missing some detail or corner case, and maybe there is a "standard" way to
do this, but I find this incredibly useful.


-----Message d'origine-----
De : devon.boyle [] 
Envoyé : Tuesday, October 13, 2009 4:51 AM
À :
Objet : Re: Is it possible to register a default resource?

Hi Sergy,

Thank you very much for your response.

I did, eventually find a trick that worked. I changed my "default" service

interface ADefaultResource {
  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.

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.


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. 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 "|".  

I'm sure this is just an artifact of some bug related to the handling of URI
Templates which terminate in a regex variable.


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,

Sergey Beryozkin wrote:
> Hi
> No problems at all and thanks for asking this question.
> The problem is that both resources match requests starting from
> /a/known/path/with or indeed with
> /a/, etc. It is not possible in JAXRS to try to find an operation on one
> matching resource and then try to do the same for another matching
> resource, etc; though a JIRA has been opened in CXF to extend the
> selection algorithm.
> So try restricting the URI space that a default resource can handle, ex,
> assuming that possible URIs are either
> /a/known/path/with/{parameters}
> or /a/known/path/with
> then    
> @path("/a/known/path/with/")
> interface AKnownResource {
>   @path("{variables}")
>   Response aKnownMethod();
> }
> @path("/a/known/path/with")
> interface ADefaultResource {
>    @GET
>    Response defaultResource();
> }
> should do it.
> By the way, can you please give a bit more info about this message :
> "No operation matching request path l is found on subresource"
> is it '|' which is actually reported in this case ? or '/' ?
> thanks, Sergey
> devon.boyle wrote:
>> Hi.
>> I'm wondering if its possible to setup a default resource/service class
>> to handle requests that don't otherwise match existing resources in the
>> server? 
>> I'm new to CXF and JAX-RS, so I apologize if this is a painfully obvious
>> question. But somehow, I couldn't find any answers to it in the
>> documentation or on the forums. Perhaps I don't know the right key words
>> yet...  At any rate, I'd really appreciate any help anyone could offer.
>> Here is a very simple example to explain what I'm trying to do:
>> interface AKnownResource {
>>   @path("/a/known/path/with/{variables}")
>>   Response aKnownMethod();
>> }
>> interface ADefaultResource {
>>   // Not sure what to put for @path()
>>   Response defaultResource();
>> }
>> With the idea that request for
>> "http://mydomain/a/known/path/with/variables" would invoke
>> aKnownMethod(), while any other URL would invoke defaultResource().
>> I've tried using the regex variable syntax to register the default
>> service, such as:
>> @Path("{path:(.)+}")
>> This successfully invokes the defaultResource() method, but then the
>> server fails to find a subresource to complete the processing of the
>> response.:
>> "No operation matching request path l is found on subresource"
>> I'm sure I am going about this all wrong. Would anyone mind pointing me
>> in the right direction?
>> Thank you,
>> -Devon

View this message in context:
Sent from the cxf-user mailing list archive at

View raw message