Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
It looks quite perfect, though you can probably simplify and avoid checking a super-class, unless you can also have for example multiple PUT operations with intersecting path values or some complex Consumes expressions... re returning 0: means you don't mind which method will be selected which

Re: JAX-RS method matching

2013-07-29 Thread John Baker
This appears to be the answer: // Check if CXF can make a decision int cxfResult= super.compare(oper1, oper2); if (cxfResult != 0) return cxfResult; Int result = 0; String s = … message body. String target=

Re: JAX-RS method matching

2013-07-29 Thread John Baker
> The relevant RC method needs to help with ordering the method > candidates, so return either -1 or 1 to help the runtime choose the > right candidate But what is "equal"? Is it the two resource infos pointing to updateFruit when i know the target is that method? So return 0 in that case? And

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 13:39, John Baker wrote: Ok I'm stumped. Given my example: @PUT @Path("/{id}") public void updateFruit(@QueryParam("id") String id, Banana banana); @PUT @Path("/{id}") public void updateAnimal(@QueryParam("id") String id, Dog dog); what should I be testing in the

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 13:05, John Baker wrote: Defining in the XML Is fine. I'm just working out how the compare method for a method is supposed to work with my example... What you can do is to do a check in your custom RC on the input stream available on the current message (message.getContent(InputStr

Re: JAX-RS method matching

2013-07-29 Thread John Baker
Defining in the XML Is fine. I'm just working out how the compare method for a method is supposed to work with my example... -- John Baker On Mon, Jul 29, 2013, at 01:02 PM, Sergey Beryozkin wrote: > On 29/07/13 12:59, John Baker wrote: > > > >> Have you read the section :-) ? > > > > Yes but n

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 12:59, John Baker wrote: Have you read the section :-) ? Yes but not well enough. It says: "Starting from CXF 2.2.5 it is possible to register a custom ResourceComparator implementation using a jaxrs:server/resourceComparator element." Actually, it has to be "jaxrs:server/jaxrs

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 12:52, John Baker wrote: use CXF ResourceComparator, http://cxf.apache.org/docs/jax-rs-basics.html#JAX-RSBasics-Customselectionbetweenmultipleresources How is the ResourceComparator implementation registered with the service? Can it be done via an annotation on the interface? H

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 12:48, John Baker wrote: I can only determine the parameter type / method by the message body, so I guess I need a generic "put" method with an object, and use the provider to create the correct object, before using an if instanceof in the method. May be you can use a custom provider

Re: JAX-RS method matching

2013-07-29 Thread John Baker
I can only determine the parameter type / method by the message body, so I guess I need a generic "put" method with an object, and use the provider to create the correct object, before using an if instanceof in the method. -- John Baker On Mon, Jul 29, 2013, at 12:46 PM, Sergey Beryozkin wrote:

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 12:41, John Baker wrote: Sergey, You can have "@Context MessageContext" or any of standard JAX-RS contexts injected into your custom provider Just to clarify, should I inject this as a class variable on the provider, ie are the providers thread safe and is the message updated on

Re: JAX-RS method matching

2013-07-29 Thread John Baker
Sergey, > You can have "@Context MessageContext" or any of standard JAX-RS > contexts injected into your custom provider Just to clarify, should I inject this as a class variable on the provider, ie are the providers thread safe and is the message updated on each call to readFrom? John

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
On 29/07/13 12:27, John Baker wrote: Hello Thanks for responding so quickly. JAX-RS selection algorithm sees these 2 methods as equal candidates. IMHO having unique paths for different type of resources (from the client's POV, not from the Java hierarchy perspective) is reasonable IMHO, but if

Re: JAX-RS method matching

2013-07-29 Thread John Baker
Hello Thanks for responding so quickly. > JAX-RS selection algorithm sees these 2 methods as equal candidates. > IMHO having unique paths for different type of resources (from the > client's POV, not from the Java hierarchy perspective) is reasonable > IMHO, but if you prefer or *have to* use t

Re: JAX-RS method matching

2013-07-29 Thread Sergey Beryozkin
Hi On 29/07/13 11:52, John Baker wrote: Hello I'm having trouble with CXF's JAX-RS implementation. The service is struggling to match the correct method defined on an interface. Please consider: @Path("/update") public interface MyService { @PUT @Path("/{id}") public void updateFruit(

JAX-RS method matching

2013-07-29 Thread John Baker
Hello I'm having trouble with CXF's JAX-RS implementation. The service is struggling to match the correct method defined on an interface. Please consider: @Path("/update") public interface MyService { @PUT @Path("/{id}") public void updateFruit(@QueryParam("id") String id, Banana banana);