@Path regexp too greedy

[jerseyrobot]

Imagine we have the following REST resource. We want the @GET method handle URLs like both "/1" and "/1/foo", so we use a regexp in @Path:

@GET
    @Path("/{id}{name: (/\\w+)?}")
    public String get(@PathParam("id") Long id, @PathParam("name") String name) {
        LOG.log(Level.INFO, "GET {0} {1}", new Object[]{id, name});
        return "Foo";
    }

    @DELETE
    @Path("/{id}")
    public void delete(@PathParam("id") Long id) {
        LOG.log(Level.INFO, "DELETE {0}", id);
    }

The @GET method works, but @DELETE gets broken (405 Method Not Allowed). Seems like @GET mapping shadows that of @DELETE, and the request is being routed to @GET handler despite HTTP method annotation.

Environment

Oracle JDK 1.8.0_31 GlassFish v4.1 b13 nightly 12-15-2014

Affected Versions

[2.13]

[jerseyrobot]

• Issue Imported From: https://github.com/jersey/jersey/issues/3039
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @mpotociar

[jerseyrobot]

@glassfishrobot Commented Reported by xwibao

[jerseyrobot]

@glassfishrobot Commented xwibao said: Also tested on TomEE (CXF) and WildFly (RESTEasy) - works OK.

I've noticed some other minor differences:

• if the optional part is present (ex. "/1/foo"), the "name" param value is:
  • TomEE: foo
  • GF: /foo
  • WF: /foo
• if absent:
  • TomEE: null
  • GF: empty string
  • WF: empty string

If needed, I can supply a working NetBeans project (though I don't see how to attach files here)

[jerseyrobot]

@glassfishrobot Commented michalgajdos said: Thank you for filing the issue, moving to backlog for now.

[jerseyrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JERSEY-2767