As I recall there was an open issue for adding all the needed lifecycle hooks for integrating cleanly with something like Guice (worker lifecycle callbacks?) but I can't find it now...maybe STORM-172 .
In any case, I think there is an issue with not having quite enough exposed from storm to properly integrate things like Guice. Having said that, I'm using Guice now, but it is basically a hack until I can find a better way. The key to my hack is that injectors are not serializable, but modules are. I use the singleton pattern with static accessor to hold the injector which is created lazily (i.e. after topology components have been deserialized and are running in the worker VM). I instantiate my guice module during topology build and it gets serialized as part of the topo definition. In my storm components, I pass the module to the singleton injector factory which creates the injector from the passed module if one doesn't exist in the VM, and just returns the existing injector otherwise. Finally, with an injector in hand for the prepare method, I can then either do a injector.getInstance() to create objects (e.g. inside a trident state factory) or injector.injectMembers(this) in a prepare method if my topology component has transient @Inject fields for dependencies (since storm controls the object lifecycle and I can't use constructor injection there) The biggest problem with this hack is it assumes that all module instances are interchangeable (and identical) and the first component to init gets to build the injector. With the right lifecycle hooks, the injector could be created in a cleaner way. On Tue, Mar 25, 2014 at 12:45 PM, Software Dev <[email protected]> wrote: > > How would you go about use DI (Google Guice) with a Storm cluster? The > worker nodes themselves will not have access to the Injector instance > after job submission. > > Thanks
