Re: JAX-RS Request Matching Wierdness
No problems - I've misread that part of the specification for a number of times
:-)
The spec allows for Objects or interfaces with no JAX-RS annotations classes be returned as subresources so what you suggest will
not work. That said it is something I'll keep in mind. In CXF you can set an 'enableStaticResoultion' property on a given endpoint
and it will result in a complete traversal at startup. So may be we can indeed optimize and possibly extend the selection
algorithm...
cheers, Sergey
- Original Message -
From: "Tong, Gary"
To:
Sent: Monday, July 13, 2009 12:09 PM
Subject: RE: JAX-RS Request Matching Wierdness
Ah nevermind. Just read the spec again and I realized that I had misread it
the first time and that CXF works as the spec says.
To be honest though, after reading the JSR the right way, the algorithm it
talks about actually seems a bit less functional than it
could be. I would think that a initial scan of all root resource classes at
startup and putting all valid resource/sub-resources
into a gigantic mapping, and then filtering that map for each request would be
a more robust way of doing things.
Anyway, thanks for looking into this.
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 12 July 2009 20:20
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
The thing is that JAX-RS does not allow for checking on the multiple root
resource classes - I think there was a discussion on cxf
users list about extending the selection algorithm - I don't mind if it would
actually make things simpler.
Please see few more comments prefixed with S.B below. Particularly I don't
understand why the use of subresources affects the
complexity of response objects
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 12 July 2009 11:52
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple service
beans. The simplest case is the following:
public class AWebService {
@GET
@Path("/a")
public String a() {
return "a";
}
}
public class BWebService {
@GET
@Path("/b")
public String b() {
return "b";
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other more
concrete use cases that cause issues. For instance, if I
had the following URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff on a
SearchWebService that uses @Path("/{type}/search") then
that wouldn't work in CXF.
S.B :
Try
@Path("/user")
public class UserService {}
@Path("/user/")
public class SearchService {}
S.B : - note the trailing '/' in SearchService. It might do the trick
in other cases too
Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService, but if
I wanted PostWebService to handle /user/{id}/posts as
just a specialized version of /posts that would be tricky with CXF. It's
doable with sub-resource locators, but then my response
objects start getting complicated.
S.B : I'm not quite sure why the use of subresources affects the
complexity of the response objects. Can you give an example please ?
Thanks,
Gary
-----Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of criteria.
Another thing is that the JAX-RS selection algorithm
does not have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to apply a
series of steps to determine which URL to use for
the request.
Instead, CXF applies a path filter at the class level, and then returns the
first entry it finds. Specifically the code that does
this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.Entry>
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know a
RE: JAX-RS Request Matching Wierdness
Ah nevermind. Just read the spec again and I realized that I had misread it
the first time and that CXF works as the spec says.
To be honest though, after reading the JSR the right way, the algorithm it
talks about actually seems a bit less functional than it could be. I would
think that a initial scan of all root resource classes at startup and putting
all valid resource/sub-resources into a gigantic mapping, and then filtering
that map for each request would be a more robust way of doing things.
Anyway, thanks for looking into this.
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 12 July 2009 20:20
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
The thing is that JAX-RS does not allow for checking on the multiple root
resource classes - I think there was a discussion on cxf users list about
extending the selection algorithm - I don't mind if it would actually make
things simpler.
Please see few more comments prefixed with S.B below. Particularly I don't
understand why the use of subresources affects the complexity of response
objects
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 12 July 2009 11:52
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple service
beans. The simplest case is the following:
public class AWebService {
@GET
@Path("/a")
public String a() {
return "a";
}
}
public class BWebService {
@GET
@Path("/b")
public String b() {
return "b";
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other more
concrete use cases that cause issues. For instance, if I had the following
URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff on a
SearchWebService that uses @Path("/{type}/search") then that wouldn't work in
CXF.
> S.B :
Try
@Path("/user")
public class UserService {}
@Path("/user/")
public class SearchService {}
> S.B : - note the trailing '/' in SearchService. It might do the trick
in other cases too
Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService, but if
I wanted PostWebService to handle /user/{id}/posts as just a specialized
version of /posts that would be tricky with CXF. It's doable with sub-resource
locators, but then my response objects start getting complicated.
> S.B : I'm not quite sure why the use of subresources affects the
complexity of the response objects. Can you give an example please ?
Thanks,
Gary
-Original Message-----
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of criteria.
Another thing is that the JAX-RS selection algorithm does not have be
implemented literally the way it's documented in the spec, rather the final
result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to apply a
series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns the
first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.Entry>
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
Cheers,
Gary
--
NOTICE: If received in error, please destroy, and notify sender. Sender does
not intend to waive confidentiality or privilege. Use of this email is
prohibited when received in error. We may monitor and store emails to the
extent permitted by applicable law.
--
NOTICE: If received in error, please destroy, and notify sender. Sender does
not intend to waive confidentiality or privi
RE: JAX-RS Request Matching Wierdness
Hi Gary
The thing is that JAX-RS does not allow for checking on the multiple
root resource classes - I think there was a discussion on cxf users list
about extending the selection algorithm - I don't mind if it would
actually make things simpler.
Please see few more comments prefixed with S.B below. Particularly I
don't understand why the use of subresources affects the complexity of
response objects
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 12 July 2009 11:52
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple
service beans. The simplest case is the following:
public class AWebService {
@GET
@Path("/a")
public String a() {
return "a";
}
}
public class BWebService {
@GET
@Path("/b")
public String b() {
return "b";
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other
more concrete use cases that cause issues. For instance, if I had the
following URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff
on a SearchWebService that uses @Path("/{type}/search") then that
wouldn't work in CXF.
> S.B :
Try
@Path("/user")
public class UserService {}
@Path("/user/")
public class SearchService {}
> S.B : - note the trailing '/' in SearchService. It might do the trick
in other cases too
Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService,
but if I wanted PostWebService to handle /user/{id}/posts as just a
specialized version of /posts that would be tricky with CXF. It's
doable with sub-resource locators, but then my response objects start
getting complicated.
> S.B : I'm not quite sure why the use of subresources affects the
complexity of the response objects. Can you give an example please ?
Thanks,
Gary
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of
criteria. Another thing is that the JAX-RS selection algorithm does not
have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to
apply a series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns
the first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.Entry>
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
Cheers,
Gary
--
NOTICE: If received in error, please destroy, and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error. We may monitor and store emails to
the extent permitted by applicable law.
--
NOTICE: If received in error, please destroy, and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error. We may monitor and store emails to
the extent permitted by applicable law.
RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple service
beans. The simplest case is the following:
public class AWebService {
@GET
@Path("/a")
public String a() {
return "a";
}
}
public class BWebService {
@GET
@Path("/b")
public String b() {
return "b";
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other more
concrete use cases that cause issues. For instance, if I had the following
URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff on a
SearchWebService that uses @Path("/{type}/search") then that wouldn't work in
CXF. Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService, but if
I wanted PostWebService to handle /user/{id}/posts as just a specialized
version of /posts that would be tricky with CXF. It's doable with sub-resource
locators, but then my response objects start getting complicated.
Thanks,
Gary
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of criteria.
Another thing is that the JAX-RS selection algorithm does not have be
implemented literally the way it's documented in the spec, rather the final
result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to apply a
series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns the
first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.Entry>
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
Cheers,
Gary
--
NOTICE: If received in error, please destroy, and notify sender. Sender does
not intend to waive confidentiality or privilege. Use of this email is
prohibited when received in error. We may monitor and store emails to the
extent permitted by applicable law.
--
NOTICE: If received in error, please destroy, and notify sender. Sender does
not intend to waive confidentiality or privilege. Use of this email is
prohibited when received in error. We may monitor and store emails to the
extent permitted by applicable law.
RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of
criteria. Another thing is that the JAX-RS selection algorithm does not
have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to
apply a series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns
the first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.Entry>
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
Cheers,
Gary
--
NOTICE: If received in error, please destroy, and notify sender. Sender
does not intend to waive confidentiality or privilege. Use of this email
is prohibited when received in error. We may monitor and store emails to
the extent permitted by applicable law.
