Give me the complete info please: @PathParam, HTTP verb present on both
methods or not, @Consumes/@Produces,
I'm assuming it is @Path("/foo/bar") for foo() and @Path("/foo/{id}")
for foo(Lomg l)
On 13/10/11 17:01, Romain Manni-Bucau wrote:
I tried 2.4.3.
Signature 1 foo()
Signature 2 foo(Long l)
- Romain
Le 13 oct. 2011 17:55, "Sergey Beryozkin"<sberyoz...@gmail.com> a écrit :
It does not work with 2.4.2 ?
Can you also send me the signature of the 2 methods ?
cheers, Sergey
On 13/10/11 16:46, Romain Manni-Bucau wrote:
it doesn't seem to work, maybe because the type is not matching:
/foo/123
/foo/{id}
here id and 123 are long so it works but
/foo/{id}
/foo/bar
here id and bar have different types so it doesn't match.
am i wrong?
- Romain
2011/10/13 Sergey Beryozkin<sberyoz...@gmail.com**>
Hi
On 12/10/11 21:34, Romain Manni-Bucau wrote:
Hi,
thanks for this reply,
i use cxf through OpenEJB and the version is the 2.4.1, do you know if
it
was already included?
There was only one relevant fix after 2.4.1:
https://issues.apache.org/****jira/browse/CXF-3608<https://issues.apache.org/**jira/browse/CXF-3608>
<https://**issues.apache.org/jira/browse/**CXF-3608<https://issues.apache.org/jira/browse/CXF-3608>
If you have in 2.4.1
class Root {
@Path("/foo/bar")
SomeSubresource getSubresource() {}
@Path("/foo/{id}")
@GET
SomeData get(@PathParam("id") Long id) {}
}
then indeed, /foo/bar will be wrongly handled by get(). May be you are
seeing exactly this issue in 2.4.1. That must be fixed in 2.4.2 - give it
a
try please
thanks, Sergey
- Romain
2011/10/12 Sergey Beryozkin<sberyoz...@gmail.com****>
Hi
That must work, which CXF version do you use ?
I've added a test locally and it just works, see the diff below as this
has
to be already tested on the trunk, so I'm not merging it at the moment.
Try please 2.3.7/2.4.3
thanks, Sergey
Index: src/test/java/org/apache/cxf/******systest/jaxrs/**
JAXRSClientServerBookTest.java
==============================******==========================**==**
==**=======
--- src/test/java/org/apache/cxf/******systest/jaxrs/****
JAXRSClientServerBookTest.java
(revision 1182563)
+++ src/test/java/org/apache/cxf/******systest/jaxrs/****
JAXRSClientServerBookTest.java
(working copy)
@@ -950,6 +950,20 @@
}
@Test
+ public void testGetBook222() throws Exception {
+ WebClient wc = WebClient.create("http://******localhost<
http://localhost>:"
+ PORT + "/bookstore/books/222");
+ Book book = wc.get(Book.class);
+ assertEquals(222L, book.getId());
+ }
+
+ @Test
+ public void testGetBook333() throws Exception {
+ WebClient wc = WebClient.create("http://******localhost<
http://localhost>:"
+ PORT + "/bookstore/books/333");
+ Book book = wc.get(Book.class);
+ assertEquals(333L, book.getId());
+ }
+
+ @Test
public void testGetBook123() throws Exception {
getAndCompareAsStrings("http:/******/localhost<http://**
localhost<http://localhost>>**:"
+
PORT + "/bookstore/books/123",
"resources/expected_get_******
book123.txt",
Index: src/test/java/org/apache/cxf/******systest/jaxrs/BookStore.**
java
==============================******==========================**==**
==**=======
--- src/test/java/org/apache/cxf/******systest/jaxrs/BookStore.**java
(revision 1176840)
+++ src/test/java/org/apache/cxf/******systest/jaxrs/BookStore.**java
(working
copy)
@@ -477,12 +477,25 @@
}
@GET
+ @Path("/books/222")
+ @Produces("application/xml")
+ public Book getBook222(@PathParam("bookId"******) String id)
throws
BookNotFoundFault {
+ return new Book("222", 222);
+ }
+
+ @GET
@Path("/books/{bookId}/")
@Produces("application/xml")
public Book getBook(@PathParam("bookId") String id) throws
BookNotFoundFault {
return doGetBook(id);
}
+ @GET
+ @Path("/books/333")
+ @Produces("application/xml")
+ public Book getBook333(@PathParam("bookId"******) String id)
throws
BookNotFoundFault {
+ return new Book("333", 333);
+ }
@GET
On 12/10/11 19:19, Romain Manni-Bucau wrote:
Hi,
i wonder if it is normal (which i don't think if i write this mail) or
not:
why cxf is taken the first method matching a uri pattern when a rest
service
is called?
as an example is clearer than any speech:
why these patterns are not guarantee to work:
/foo/{id} # id = Long for instance
/foo/bar
as the first one will match the second one the result will depend on
the
order of declaration and if the second takes the first one an error
will
appear, something like bar cannot be converted to Long.
- Romain
