Thanks for the pointer.

I haven't decide if I will deploy it yet. I will try it and see what 
BingPreview is doing with the subsequent calls. If it is a very big hassle to 
make it work I will probably leave it as it is altogether.

Anyway I didn't know about ContainerRequestFilter so that was good to learn.

The following works for me

@PreMatching
public class AcceptWildcardContainerRequestFilter
        implements ContainerRequestFilter {
    private final Log log = LogFactory.getLog(getClass());

    @Override
    public void filter(ContainerRequestContext context) throws IOException {
        final String accept_header = "Accept";
        final String accept_value = context.getHeaderString(accept_header);
        if (accept_value != null && accept_value.equals("*/*")) {
            log.debug("Modifying accept header: " + accept_value);
            context.getHeaders().putSingle(accept_header, "application/json");
        }
    }
}

Thanks again.

    Vassilis

On 08/10/2017 06:42 PM, Sergey Beryozkin wrote:
Hi

as far as I recall, Jackson provider checks in its isReadable if MediaType is 
application/json.

Have a Pre-Match container request filter which changes content type to 
application/json if it is a wildcard.

Cheers, Sergey
On 10/08/17 15:42, Vassilis Virvilis wrote:
Hi everybody,

I am using cxf-3.1.7 with jax-rs and JacksonJsonProvider

My application works normally but when BingPreview tries to crawl my page I get

ERROR 2017-08-10 12:32:51,561 ajp-nio-8009-exec-4: 
org.apache.cxf.jaxrs.utils.JAXRSUtils.logMessageHandlerProblem(JAXRSUtils.java:1811):
 No message body writer has been found for class com.lib.datatype.Config, 
ContentType: */*

BingPreview is a Microsoft bot that generates page preview and apparently can 
ran JavaScript. Here is the user_agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 
like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 
Mobile/11A465 Safari/9537.53 BingPreview/1.0b

Apparently BingPreview calls my method with Accept: */* instead of 
"application/json"

I can recreate the behavior with curl

curl -iH "application/json" http://... works as expected
curl -i http://... gives the same error

The question is the following: Since the client explicitly specified that accepts 
anything why CXF has a problem with that and throws an exception? It should return 
"application/json" and specify that to the ContentType not throw an exception? 
Right? Wrong? What do you think?

    Vassilis

Reply via email to