Hi,
apologies for jumping in here but I just wanted to get some
clarification. Just as a bit of background, I originally discussed
this as regards CXF with Sergey who was kind enough to raise the issue
here. This CXF JIRA entry might give some more background on the
problem:
https://issues.apache.org/jira/browse/CXF-1572
Anyway, if I read this correctly the conclusion being drawn here is
that the spec doesn't support differentiation between URLs where
literals are mixed in with {variables}. For example, that it cannot
distinguish between /{a}/{b}/{c}/d and /{a}/{b}/{c}/d/{e}.Is that
correct?
I'm not try to criticise anyone or knock the work thats been done
here, the JSR as a whole is excellent and we are happy to be using it.
My only thought is that for a spec supporting REST technology where
the URL is a major part of the concept. Shouldn't that sort of thing
be supported?
I hope that doesn't sound too critical. I appreciate the effort that
has been put into this JSR for the benefit of the community and people
like me who are getting value from it.
Thanks,
Brad.
On Wed, May 7, 2008 at 5:58 PM, Marc Hadley <Marc.Hadley_at_sun.com> wrote:
> On May 7, 2008, at 5:19 AM, Sergey Beryozkin wrote:
>
> > >>
> > >> Consider this class :
> > >>
> > >> @Path("{a}/{b}/{c}/d")
> > >
> > > I assume there should be {} around d above.
> >
> > No, there's no {} around d there. I think it's a valid URI Template
> expression ?
> >
> >
> Its valid but it wouldn't match the example URIs you use below. E.g.
> /1/2/3/d would match but /1/2/3/4 wouldn't since 'd' is a literal character
> rather than a path parameter.
>
>
>
> > >
> > >> public class FooClass {
> > >>
> > >> @GET
> > >> public Bars listBars() {
> > >> return bars;
> > >> }
> > >>
> > >> @GET
> > >> @PATH("/{e}")
> > >> public Bar readBar() {
> > >> return bar;
> > >> }
> > >> }
> > >>
> > >> In CXF a request like URI /1/2/3/4 is delegated to readBar() but the
> > >> user is expecting listBars be invoked and I'm wondering, where
> > >> exacly CXF fails to follow the spec...
> > >> Both methods match the request and both methods are added to the list.
> > >>
> > > listBars would match since there's no trailing '/' on the request URI.
> > > readBar would only match if you used /1/2/3/4/ or /1/2/3/4/something.
> >
> >
> > I'm sorry, I think may be I don't understand well this algorithm. So I'd
> like to ask for some more clartifications until I do understand it well...
> >
> > Here's what I can see in the spec :
> >
> > Section 3.2.6/2.a : If U is null or '/' go to step
> >
> >
> It sounds like you are using an older version of the specification, the
> matching algorithm is described in section 3.7 these days. Could you review
> a more recent version of the spec and if there are still questions then at
> least we'll definitely be talking about the same thing. You can get a link
> to the latest from:
>
> http://jsr311.dev.java.net/
>
>
>
> >
> > So, if /1/2/3/4/ is used then U is '/' after the root class has been
> selected (or null if /1/2/3/4 is used) and hence listBar() should be
> selected in 3.2.6/3 ?
> >
> > Should readBar be selected only when /1/2/3/4/something is used ?
> >
> >
> > Here's another question.
> > Section 3.2.6/2.f : Sort E using the number of literal characters in each
> member as the primary key...
> >
> > What exactly is *the number of literal characters* ? There's a footnote
> for 3.2.6/1e :
> > 2Here, literal characters means those not resulting from template variable
> substitution.
> >
> >
> > Does the same footnote applies to 3.2.6/2.f ?
> >
> > Some example would be appreciated.
> >
>
> Literal characters means those not part of path parameters. So, e.g. if the
> URI template is "foo.{ext}" then the literal characters are "foo.". Is that
> clearer ?
>
> Marc.
>
>
>
> >
> > >
> > > Section 3.7 describes the algorithm used to match requests to resource
> > > classes and methods.
> > >
> > > Marc.
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> >
>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>