1

Anybody knows how to disable autodiscovery and manually register JacksonFeature, just to be completely sure that in case there are several providers in the classpath that is the one used?

Everything is working by default, with the lines of the following helper commented. Then I try to register JSON provider by hand, so I uncomment lines and specify 

private void disableAutoDiscoveryAndUseJacksonProvider(ResourceConfig config) {
        config.property(CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE, true);
        // config.property(CommonProperties.METAINF_SERVICES_LOOKUP_DISABLE, true);
        // config.property(CommonProperties.JSON_PROCESSING_FEATURE_DISABLE, false);
        config.register(JacksonFeature.class);
}

context.addServlet(new ServletHolder(new ServletContainer(config)), "/*");

Same logic works when using a client with:

     javax.ws.rs.client.Client client =
     javax.ws.rs.client.ClientBuilder.newBuilder().register(JacksonFeature.class).build();

EDIT: As I cannot work it out, I'm trying to replicate default behaviour in an explicit way.

ServletHolder holder = new ServletHolder(new ServletContainer()) // No Config

Called that way, and putting just Jackson in the path the application works (objects deserialize correctly) But if I make a ResourceConfig explicit as in:

 ResourceConfig config = new ResourceConfig();
 //config.property(X,default)
 ServletHolder holder = new ServletHolder(new ServletContainer(config));

I get a deserializing error

I try to mimic the default behaviour explicitly by specifying all the combinations of CommonProperties.* like config.property(X,default), config.property(Y,default) but still no luck, any ideas what is happening behind?

Whimusical
  • 6,401
  • 11
  • 62
  • 105
  • Your code seems to answer your own question. Is there something not working about this? – Paul Samsotha Jan 15 '15 at 03:03
  • If I don't touch ResourceConfig, Jackson serializes well. If I add those lines above, everything breaks, and my object throws an exception when unmarshalled in the endpoint – Whimusical Jan 15 '15 at 09:19
  • I would imagine that if you use the _global_ `CommonProperties.FEATURE_AUTO_DISCOVERY_DISABLE`. You would have to register everything explicitly, not just Jackson. – Paul Samsotha Jan 15 '15 at 09:31
  • This has a lot of sense. So if I don't turn off autodiscovery how can I indicate which provider I want by default in case there are several in classpath? – Whimusical Jan 15 '15 at 09:32
  • 2
    If it's a provider you implemented, most likely that will win, based on the `@Provides/@Consumes` specifvity and others. If its a third-party implementation, unless they provide a `Feature` that loads the provider, it shouldn't be auto-loaded. If it is auto-loaded, then provider chosen is based on the algorithm in [the spec 4.2](https://jsr311.java.net/nonav/releases/1.1/spec/spec.html). Most implementations with a `Feature` should come with a property that can switch on and off. In the case of MOXy, any registered provider featue will override it. So it really depends on the exact scenario. – Paul Samsotha Jan 15 '15 at 09:43
  • I'd like to not work by exception, but by indicating the proper one. Could you review my last edit so maybe we get an idea of how to solve it? – Whimusical Jan 15 '15 at 09:56
  • I sharpened a bit my question for now, as I am narrowing the area of conflict: http://stackoverflow.com/questions/27965207/creating-a-resourceconfig-that-behaves-the-same-way-as-default-jettys-jersey-re – Whimusical Jan 15 '15 at 14:07

0 Answers0