replace io.dropwizard.jackson.Discoverable mechanism with Jackson modules?

[Ron Dagostino]

As mentioned in this user group topic I discovered that extending the io.dropwizard.jackson.Discoverable interface is not strictly necessary for custom configuration classes to work.  Tatu mentioned the Jackson Module mechanism as a potential tool in that topic, and it occurred to me that it would indeed be nice to be able to package up configuration classes as a Jackson Module because then the module could be used both without Dropwizard. as well as with Dropwizard.  They key to using a Jackson module for configuration classes, though, is to have a way for such modules to be dynamically discovered and registered with Jersey prior to loading configuration classes.  Do people believe putting such a "Jackson Module Discovery" mechanism in place is a reasonable idea?  It also occurs to me that the current io.dropwizard.jackson.Discoverable mechanism could then be rewritten as a module, which would unify everything into one general mechanism.

Ron  

[Ron Dagostino]

Actually, now that I take a closer look, it seems to me that the io.dropwizard.jackson.Discoverable mechanism is totally unnecessary. A much simpler mechanism is to create a Jackson module that registers your subtypes and then simply register the module in your application's initialize(Bootstrap) method via bootstrap.getObjectMapper().registerModule(new MyConfigClassModule());

 

This alternate Jacksom module approach has multiple advantages.  Fiirst, it eliminates the need to create any META-INF/services classes (which I find to be annoying and cumbersome, especially if/when I rename config classes).  Second, it relies completely on Jackson -- there is nothing Dropwizard-specific about it.  Third, while I am not sure about this, it creates the potential to eliminate the org.apache.maven.plugins.shade.resource.ServiceResourceTransformer requirement (forgetting to include thisis a not-uncommon mistake for Dropwizard beginners).

 

There is one disadvantage: the need to explicitly register any config class module that you want to use.  The current mechanism "just works" out-of-the-box, which is a better end-user experience.  One way around this would be to also make the module mechanism "just work" -- perhaps by looking at a file called META-INF/services/com.fasterxml.jackson.databind.Module and then explicitly instantiating an instance (via a default constructor) for every class listed there and registering it as a Jackson module.  It keeps the org.apache.maven.plugins.shade.resource.ServiceResourceTransformer requirement but gives a better end-user experience.

 

Am I missing something?

 

Ron

[babc...@umich.edu]

Is what you are describing currently achievable in the bootstrap phase? If so, this definitely warrants a documentation addition, as I know that my first time trying to get Discoverable to work took me a couple tries. I would have appreciated a more familiar approach.

If the new technique is obviously superior and dropwizard internally can make use of this technique, then I see no reason stopping Discoverable being deprecated.

[Ron Dagostino]

Yes, unless I am missing something (definitely a possibility since I'm relatively new to Dropwizard) the module approach is available right now and warrants a doc change to mention (recommend?) the approach.  Again assume I am not missing anything, it is worth discussing the possibility of improving the end-user experience by adding code to read something like a META-INF/services/com.fasterxml.jackson.databind.Module file and automatically registering any modules listed there -- then a Maven dependency combined with the shade plugin would be sufficient to get the module loaded -- it would "just work"

Ron

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-dev/E4Jw99rHtVI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dropwizard-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jochen Schalanda]

Hi,

Again assume I am not missing anything, it is worth discussing the possibility of improving the end-user experience by adding code to read something like a META-INF/services/com.fasterxml.jackson.databind.Module file and automatically registering any modules listed there -- then a Maven dependency combined with the shade plugin would be sufficient to get the module loaded -- it would "just work"

How would that be different from the current approach using the standard Java ServiceLoader interface except that it introduces a dependency on a Jackson feature?

Cheers,

Jochen

[Ron Dagostino]

Hi Jochen.  Something like a META-INF/services/com.fasterxml.jackson.databind.Module file would be the only file a developer would have to create in order to register multiple interfaces, abstract classes, and concrete subtypes with Jackson.  Currently you have to create the META-INF/services/io.dropwizard.jackson.Discoverable file to list the interfaces and abstract classes, and then you have to create one file for each such interface or abstract class to list all of its corresponding concrete subtypes.

There is another advantage of using a Jackson module that I recently discovered.  The code that implements the module (probably by extending com.fasterxml.jackson.databind.module.SimpleModule) has the flexibility to do whatever it wants, so it is possible to leverage Jackson's mixin feature and keep the Jackson annotations off of the interfaces, abstract classes, and concrete subtypes.  We have a desire to reuse these classes without bringing in a Jackson dependency under certain circumstances, and the
META-INF/services/io.dropwizard.jackson.Discoverable mechanism doesn't support doing this.

Ron

--