On 13/01/16 13:53, Sergey Beryozkin wrote:
Hi
On 13/01/16 13:05, Jim Talbut wrote:
Gaah!!!!
You're right.
Thank you.
I haven't touched this code for a long while and didn't realise I had
overloaded that method (I've now renamed the methods to help me out next
time).
I'm surprised that a request with an Accept of this:
application/json, text/plain, */*
Do you have any 'q' parameters in this Accept ?
And no text/html ? Usually a browser inserts it
Cheers, Sergey
Thanks, Sergey
Preferred this method:
@Produces({MediaType.TEXT_HTML})
over this:
@Produces({RepresentationFactory.HAL_JSON,
RepresentationFactory.HAL_XML,
MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML,
MediaType.TEXT_XML
})
I guess you just iterate through the methods (with unpredictable
ordering) and take the first that matches, rather than trying to
establish the best?
Or do you order based on the Produces order, where the two matching
types are both third in the list?
I've changed the request to have:
Accept: application/hal+json, application/json
(which is what it should have been all along, the client couldn't cope
with anything else) and now it hits the right method.
Thank you again.
Jim
On 13/01/2016 12:32, Sergey Beryozkin wrote:
Hi
The log shows that a method accepting a single parameter is invoked,
while the one you typed accepts 3 parameters.
Looks like you may have 2 methods which prove to be equal JAX-RS method
candidates.
Cheers, Sergey
On 12/01/16 20:09, Jim Talbut wrote:
Hi,
In a JAX-RS application running in tomcat 8 using CXF 3.1.4 with the
logs turned up to DEBUG I'm seeing this:
15:59:52.116 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on
interceptor
org.apache.cxf.interceptor.OneWayProcessorInterceptor@3b258a06
15:59:52.116 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on
interceptor
org.apache.cxf.interceptor.ServiceInvokerInterceptor@22d2b4b
15:59:52.116 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.c.s.invoker.AbstractInvoker - Invoking method public
javax.ws.rs.core.Response
com.groupgti.scheduler.api.resource.TaskRunsResource.get(int) throws
java.io.IOException,org.apache.cxf.jaxrs.ext.search.SearchParseException
on object com.groupgti.scheduler.api.resource.TaskRunsResource@61f150ac
with params [426347].
15:59:52.117 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on
interceptor
org.apache.cxf.interceptor.OutgoingChainInterceptor@6bdd002e
15:59:52.117 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by bus:
[com.groupgti.esb.cxf.interceptors.MessageLoggerOutbound@716e7107,
org.apache.cxf.ws.policy.PolicyOutInterceptor@71c4ebf3]
15:59:52.117 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by
service: []
15:59:52.117 [http-apr-172.28.9.212-8080-exec-31] DEBUG
o.a.c.i.OutgoingChainInterceptor - Interceptors contributed by
endpoint:
[org.apache.cxf.interceptor.MessageSenderInterceptor@2061f639]
Note that it invokes my method and then the next log record is for an
interceptor on the outgoing chain.
An excerpt of my resource class looks like this:
@Path("/taskruns")
@LinkRelation( name = "taskruns", relation = "taskruns", title = "Task
Runs" )
public class TaskRunsResource extends AbstractResource {
private static final Logger LOG =
LoggerFactory.getLogger(TaskRunsResource.class);
@GET
@Path("{id: \\d+}")
@Produces({RepresentationFactory.HAL_JSON,
RepresentationFactory.HAL_XML, MediaType.APPLICATION_JSON,
MediaType.APPLICATION_XML, MediaType.TEXT_XML})
public Response get( @PathParam("id") int taskRunId
, @QueryParam("field") final String[] fields
, @QueryParam("embed") final String[] embeds
) throws IOException, SearchParseException {
LOG.warn("Get taskrun {}", taskRunId);
So somehow CXF thinks it is invoking that method, but it never gets as
far as that LOG expression.
Other calls are working, this is the only one I've found that isn't,
but
it fails consistently.
It does work when run in a junit that isn't using tomcat.
Can anyone suggest where I should start to look for the cause of this
problem?
Thanks.
Jim
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
