Question

I’m having some troubles understanding how Guice’s singleton instantiations works. I’ve read the available documentation (here – http://code.google.com/p/google-guice/wiki/Scopes ), but I still can’t figure out some things:

1. I’ve integrated Guice with Tomcat, and I’ve set up some bindings in a ServletModule:

   bind(MyServlet.class).asEagerSingleton();
   serve("myUrl").with(MyServlet.class);
   serve("myOtherUrl").with(MyOtherServlet.class);
   

   (where MyOtherServlet class has a @Singleton annotation above it)
   My intention here was to have two servlets, where one is eagerly instantiated, while the other isn’t. However it seems like the "serve… with…" line automatically instantiates servlets objects, even though that class is not bound as an eager singleton.
   The link I attached above mentions difference between Guice running under Stage.Development and Stage.Production – however this still happened even when I explicitly used Stage.Development (which is the default one anyway).
   Is there any way to avoid this?

2. (continues 1) Trying to ensure that MyServlet gets instantiated first even though all servlets instantiate eagerly now, I’ve modified the order of modules (and binding statements) when creating an Injector, so that the binding for MyServlet appears first. However, I found that it still gets instantiated later than some other bindings (of non-servlet classes), which were of the form:

   bind(MyInterface.class).to(MyClass.class).asEagerSingleton()
   

   even though those other bindings appeared later in the modules/bindings order.
   I’ve looked into it, and found that Guice simply instantiates eager singletons which were bound by the form of "bind… to… asEagerSingleton()" before it does ones of "bind… asEagerSingleton()", and so I solved it by modifying the line:

   bind(MyServlet.class).asEagerSingleton();
   

   into:

   bind(MyServletDummyInterface.class).to(MyServlet.class).asEagerSingleton()
   

   and that actually worked. Still, I’d rather avoid having a dummy interface just to solve this, so I was wondering if anyone had a better solution for this..?

3. I have two Guice modules – one ServletModule and one AbstractModule.
   The ServletModule configureServlets() has the following binding in it:

   serve("aUrl").with(SomeServlet.class);
   The AbstractModule’s configure() has the following bindings:

   bind(SomeImpl.class).asEagerSingleton();
   bind(SomeInterface.class).to(SomeImpl.class).in(Singleton.class);
   

Additionally, The SomeServlet class has an injected field of type SomeInterface, and has a @Singleton annotation on top of the class.

Now, one would expect that upon creating an injector, the SomeImpl class will get instantiated, and the same instance will be injected into the SomeServlet instance. As mentioned before, servlets bounded with a "serve… with…" statement also seem to get eagerly instantiated, but either way there should still be only one SomeImpl object instantiated. Yet for some reason, I got two SomeImpl objects instantiated when doing this.
To get around it, I mixed the two lines in configure() a bit, and instead of the above I had there the following lines:

bind(SomeImpl.class).in(Singleton.class)
bind(SomeInterface.class).to(SomeImpl.class).asEagerSingleton();

and then it worked fine, and I got only one instance of SomeImpl instantiated. I don’t really get why the switch should matter – I can see how the latter way is "better", but I’d expect both to work correctly, so I’m just wondering if I’m getting something wrong here…

Answer 1

1) There is no way to avoid this, since Guice calls the init() method of all servlets on initialization of its own filter pipeline and thus constructs them all. If you really need such lazy initialization logic, you should place it into the servlet itself (or use a decoupled helper class, or… there are many ways, depending on your use case).

2) Generally said, the modules of Guice declare bindings, there are not designed to be bootstrap definitions with precise instantiation orders. If you need such a defined instantiation order, create the objects yourself in the desired order and bind them via bind(...).toInstance(...). If you need injection in the self constructed instances you may use requestInjection(...) (if field/method injection is sufficient, it’s more cumbersome for constructor injection).

3) The scope of Guice applies to the binding key, not the binding value, Applying Scopes describes why only your second example is working as intended.