Skip to content


Rationalize object lifecycles #35

codahale opened this Issue · 3 comments

4 participants

Dropwizard member

Because so much of Dropwizard is glue code, the way in which things are created, configured, and wired together could use a bit more love.

  • Jersey servlet container
    • enable/disable Jersey features
    • swap out for a GuiceContainer or what have you
  • Jackson factory/mapper
    • add modules, etc. for ConfigurationFactory and JacksonMessageBodyProvider
    • enable/disable features for specific instances (e.g., ConfigurationFactory needs to always reject unknown fields)
  • MetricsRegistry/HealthCheckRegistry
    • really starting to regret those static factory methods
    • would make JRebel-style development reloads possible

I'm willing to dedicate some time to completing the ground work on the MetricsRegistry/HealthCheckRegistry case you mention above (i.e., removing dependency on static factory methods).

Are you looking at only factoring out the static factory methods (ala Metrics.newTimer(...)) to meet this goal, or are you also looking to allow the default registries to be replaced?


I've started working on Guice. Should the Guice AbstractModules be part of the environment's collection or the service's collection?

I actually have a GuiceContainer w/ mixed Guice/Jersey lifetime management working.


+1 for using some Guice DI love. Was just thinking about this myself.

@codahale codahale closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.