Hi Tom, It looks like you’re having a lot of success. The NPE that you have identified for void methods is a known bug in 1.0.1 (introduced by a fix for a different problem in 1.0.0) and is already fixed in 1.0.2-SNAPSHOT.
The release of 1.0.2 is planned soon - the vote would probably be running now except we thought it would be worth waiting a week or two to find out what (if anything) needed fixing based on getting the work you and JB are doing getting the whiteboard running on Karaf. As for the other issue Aries does a small amount of work to influence the relative ordering of identical resource methods based on service ranking order (as per the JAX-RS Whiteboard spec). This shouldn’t affect the scenario that you propose, but it is possible that it might. Definitely worth raising a bug with the Aries JAX-RS Whiteboard including your testcase, even if it turns out to be an issue in CXF we can feed that back (we have a pretty good line to them after the bugs we’ve found and fixed already). Tim Sent from my iPhone > On 24 Nov 2018, at 22:10, [email protected] wrote: > > I have in fact just adapted the cxf "basic" jaxrs example with the below two > resource classes and it does what I expect, and the behaviour is different to > what I get if I do the same via the Aries JAXRS whiteboard. > > Nothing in the OSGI JAXRS whiteboard spec leaves me to believe that it > introduces any different rules in this regard, so this appears to be a > behaviour that the Aries JAXRS whiteboard has introduced. Does this seem > likely? > > Thanks. > >> On 24 November 2018 at 21:53 [email protected] wrote: >> >> >> The problem I was having with the jaxrs path binding can be summarised like >> this. I have one resource: >> >> @Component(immediate = true, service = TestResource.class) >> @Path("test") >> @JaxrsResource >> public class TestResource { >> >> @Path("{a}") >> public Object getA(@PathParam("a") String a) { >> return new ResourceA(a); >> } >> >> public static class ResourceA { >> private String a; >> public ResourceA(String a) { >> this.a = a; >> } >> >> @GET >> @Path("{b}") >> public Response getB(@PathParam("b") String b) { >> System.out.println("test/{a}/{b} where a="+a+" and b="+b); >> return Response.ok().build(); >> } >> >> } >> } >> >> And another: >> >> @Component(immediate = true, service = TestResource2.class) >> @Path("test/a/b") >> @JaxrsResource >> public class TestResource2 { >> >> @GET >> public Response getB() { >> System.out.println("test/a/b"); >> return Response.ok().build(); >> } >> } >> >> My understanding of the jaxrs url binding is that "most specific wins". I >> believe that the above is legal, and that given a request to "test/a/b", the >> TestResource2.getB should be matched, though I haven't stepped through the >> algorithm in the jaxrs spec yet to see what it produces in this >> circumstance. However, the presence of TestResource with it's @Path of >> "test" stops anything being matched to TestResource2. >> At the moment I haven't managed to implement an example of this in "plain" >> cxf, only using Aries JAXRS whiteboard, but it's definitely something that >> "works" in jersey -- i.e, does what I expect. >> >> Not being able to quite get my mind around the Aries JAX-RS whiteboard code, >> do you think this is something that's likely to be influenced by it, or be >> purely at the CXF level? >> >> Thanks.
