np, having an extra test won't be a problem :-)
Cheers, Sergey
On 13/10/11 22:40, Romain Manni-Bucau wrote:
yep in 2.4.3 it works (i think the snapshot was not deployed last time)
sorry the my last useless mail and thank you very much for your time
- Romain
2011/10/13 Sergey Beryozkin<sberyoz...@gmail.com>
Hi
Have a look at these revisions:
trunk:
http://svn.apache.org/viewvc?**rev=1183107&view=rev<http://svn.apache.org/viewvc?rev=1183107&view=rev>
2.4.4-SNAPSHOT:
http://svn.apache.org/viewvc?**rev=1183113&view=rev<http://svn.apache.org/viewvc?rev=1183113&view=rev>
It just works. So I'm wondering, if it the fact that the invocation is
going through OpenEJB integration layer that makes a difference ?
You asked on IRC if it made sense to change JAXRSUtils.findTargetMethod a
bit to make things work - can you please check why the wrong method is
selected there in your case ? Alternatively, please open a JIRA and attach a
test maven project
Thanks, Sergey
On 13/10/11 18:55, Romain Manni-Bucau wrote:
sorry,
it is:
@GET @Path("/bar) String foo()
and
@GET @Path("/{id}") String foo(@PathParam("id"}) Long id)
and the parent has the annotation @Path("/foo"). I tried with some
@Produces
to specify plain text or xml media type but the error is the same. There
is
no consume (so no filtering at this level).
- Romain
2011/10/13 Sergey Beryozkin<sberyoz...@gmail.com**>
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"<sberyozkin@gmail.****com<
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>
<https://**issues.apache.org/****jira/**browse/CXF-3608<http://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<http://issues.apache.org/**jira/browse/**CXF-3608>
<http:/**/issues.apache.org/jira/**browse/**CXF-3608<http://issues.apache.org/jira/browse/**CXF-3608>
<https:/**/issues.apache.org/**jira/**browse/CXF-3608<http://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
