Migration from dropwizard-guice¶
The libraries are different in core guice integration aspects.
I may not be exactly correct because it's been a long time since I look how all this works. Please correct me if I'm wrong.
Dropwizard-guice rely on jersey2-guice. Injector is created on initialization dropwizard phase.
- Classpath scan for automatic registrations
- Resources could be registered directly from gucie bindings
- Resources and jersey extensions registration is the same as in core dropwizard (
- Guice bundles remain the main extension point and guice bindings might be used inside them.
- jersey2-guice hacks jersey locator lookup process which could potentially break on future versions
- Guice child injector created for each request
- Not declared services are managed by HK2 and you must be careful if you use guice AOP (as it works ony on beans, managed by guice)
Configurationobjects may be used only as
Providerin eager singletons (as injector created in initialization phase when these objects are not available)
- Admin context not covered by
GuiceFilter(no request scope injections under admin context calls).
Overall, integration feels transparent and super easy to learn (great!), but with a runtime price and caution in service definitions.
Guicey prefer guice-first approach when everything is created by guice and registered in jersey as instance (so HK2 does not manage services, resources etc.).
In contrast to dropwizard-guice, guicey brings a lot of new concepts to better integrate guice. This was necessary due to moving injector creation into dropwizard run phase (which is conceptually more correct).
Guicey abstracts user of knowing registration details and use
Installer - Extension concept:
installers did all required registrations automatically and hide boilerplate of managing extension instances with guice.
In pure dropwizard you need to:
environment.jersey().register(MyResource.class) whereas in guicey
you just need to declare extension class:
bundle.extensions(MyResource.class) and everything else would be automatic.
The same for all other extensions (tasks, health checks, jersey providers etc.): only extenion class is required for registration.
- Classpath scan for automatic registrations
- You can be sure that guice manage everything (no problems with AOP)
- Simple extensions: only extension class required (and no need to know how to install it)
- Wider range of supported extensions and ability to add more integrations (custom installers support)
- Configuration bindings (by yaml path and internal configuration object)
GuiceFilterworks on both main and admin contexts
- Integration tests support
- Resources must use
Providerfor all request-scoped injections
- Special bundles (
GuiceyBundle) should be used instead of dropwizard bundles (
Bundle) in order to use guice-related features (but, as dropwizard-guice could discover dwopwizard bundles, guicey could discover it's bundles too).
- Extra diagnostic tools usage required for debug to understand internal state (more a pro, but additional thing to know, which is a con).
Overall, guicey has much more features, cleaner guice integration and very developer friendly (customizable and with extra tooling), but with a coast of learning curve (additional concepts to know and use above dropwizard).
Only dropwizard-guice features present for comparison
|Auto scan load class to inspect||-||+|
|Auto scan recognize||Bundle, ConfiguredBundle, HealthCheck, Task, @Provider, resource (@Path), ParamConverterProvider||all the same (and more) except dropwizard bundles|
|Resources (rest) recognition directly from guice bindings||+||-|
|Resources (rest) default scope||"request"||singleton|
|Dropwizard bundle lookup||+||- (but has custom bundles lookup)|
|Injections in dropwizard Bundle||+||-|
|Injector creation customization||+||+|
|Injector creation (dropwizard) phase||initialization||run|
|Access Bootstrap, Environment, Configuration in guice modules||-||+|
|GuiceFilter contexts||main||main, admin|
Bundle registration is almost the same, just more methods available:
bootstrap.addBundle(GuiceBundle.builder() .modules(new HelloWorldModule()) // instead of addModule .enableAutoConfig(getClass().getPackage().getName()) // .setConfigClass(HelloWorldConfiguration.class) // not needed .build());
In guicey, auto scan load all classes in providied package. The logic is - application classes would be loaded in any case (in dropwizard-guice, classes are inspected by reading structure, without loading).
Auto scan will find and install extensions, with few exceptions (below)
NamedHealthCheck instead of
InjectableHealthCheck as check class.
Guicey will not find dropwizard bundles: all required bundles must be directly registered in bootstrap.
Guice injections will not work inside dropwizard bundles
But note, that bundles, used for features integrations may not be required as guicey perform automatic installation
(removes redundant code).
For reusable bundles, consider using
GuiceyBundle instead. Also, dropwzard bundles, registered in bootsrap
could be recognized as guicey bundles (to provide extra guicey features).
First of all, note that resource bound only in guice module will not be discovered (no installation from
guice declaration like it was in jersey1 guice integration).
Use either classpath scan to install resources or specify them directly into bundle:
You can still delegate jersey extensions (resources, providers) management to HK2, but they will lack guice aop and require extra dependency - HK2-guice-bridge (official HK guice bridge)
Resources are singletons by default and so they will initialize with guice context
(may be disabled).
You may need to wrap some injections with
Provider. Alternatively, you may use
Development stage for guice context or use prototype scope on resources (
@Prototype or with global option)
.printDiagnosticInfo() to see all extensions, installed by classpath scan.
.printLifecyclePhases() to indicate lifecycle phases in logs (split logs to clearly
understand onlgoing logic).
Remember that injector is created at runtime phase when
Environment objects are already present,
so no need to use
Provider for them.
Also, you may use direct access for configuration values. See:
Guicey provides more lightweight alternative to
(starts only guice context without jetty). Use it for core business logic integration tests.
Also, note that you may replace any extension or bean in context before test
Read getting started to get in common with guicey concepts