Thanks for answering.
On Thu, 30 Oct 2008 15:42:43 +0100, Marc Hadley <Marc.Hadley_at_sun.com>
wrote:
> On Oct 30, 2008, at 7:10 AM, Stephan Feder wrote:
...
>> The following pseudo example does not do what I expect (it matches
>> "index./html" instead of "index.html").
>>
>> @Path("index.")
>> public class Index {
>>
>> @GET @Path("html") @Produces("text/html")
>> public Response html() { ... }
>>
>> @GET @Path("xml") @Produces("text/xml")
>> public Response xml() { .... }
>> }
>>
> At one point we did support extension-based conneg in the spec but we
> removed it following negative feedback. You can get the kind of
> functionality you want by including the "index." in your method path
> templates (removing it from the class level @Path) or by introducing a
> second level dispatch with a template like "index.{ext}".
String concatenation of path parts does not only apply to extensions but
we can leave it at that for the sake of discussion.
Of course I thought a bit about the different ways of matching paths to
functionality and what jaxrs offers right now is not enough:
1. If I remove "index." from class level @Path the class matches the
application root. Then I cannot have another class Sitemap that is
supposed to match sitemap.xml and sitemap.html but would have to put all
top level resources into one single class which is not desirable.
Is there a particular reason to first find a matching class and then a
matching method in that class instead of finding a matching method in all
classes?
2. Programmatically dispatching requests is not desirable either because I
can no longer use annotations the same way as in my example and I end up
doing what I wish the framework to do for me.
...
>> Assuming that all Path annotations would state exactly which slashes
>> they expect I do not see any regression.
>>
> That's an assumption I don't think we can make, the changes you suggest
> would introduce a backwards compatibility problem.
You are right, of course. I did not mean the compatibility issue but
functionality. That is, is there any added value in implicitly adding
slashes that would be lost when simply appending strings?
Compatibility could be regained by introducing an annotation to indicate
the way paths are supposed to be matched. The question right now is if my
proposal is basically flawed?
Stephan