Guice Injection into Business Layer of Java Web App

I have sucessfully used Guice to Inject Providers into the servlet portion of an existing java web application, however, I can't access the injectors through the business layer (non-servlet java classes) of the application.

I have read up on Injecting the Injector, but to me that seems more like a hack and in several places, including the Guice documentation, it says not to d开发者_如何学JAVAo that too much.

I guess my question is, Where do I bootstrap a java web app so that the non-servlet/filter classes have access to the injector created in the class I use to extend GuiceServletContextListener? Is there any way to make those classes injectable without injecting the injector?

Thank you and let me know if you need any clarification.

Edit:

I am attempting to do this with a simple logger, so far, in my servlets, I call:

@Inject
   private static org.slf4j.Logger log;

The injection is set up in MyLoggerModule as follows (which is in the createInjector call with ServletModule) :

@Override
   public void configure() {
       bindListener(Matchers.any(), new SLF4JTypeListener()); // I
       built my own SLF4JTypeListener...
   }

This all works perfectly in the servlets, but the field injection does not work when called by a class that is not a servlet or filter.

Guice doesn't intercept calls for new objects, so if your business layer isn't already using Guice to create the objects that need injection, it'll need modification to do so.

The injection only works when handled by Guice during injection. So starting from the base injector you've made, whatever is marked with @Inject which is needed for the instance you've requested will be provided by Guice as best it can, and in turn, during instanciation of those, further @Inject annotations will be filled in by providers and bindings until nothing new needs to be instanciated. From that point on however you are not going to get fields injected into servlets created outside Guice's injection, perhaps by calling new somewhere, which is likely what your Object Factory is doing.

You'll need to change your Object Factory to use providers instead of new. If you could edit these, it wouldn't be too hard to do since Guice can give you default providers for bindings.

So one way your business layer could be Guice aware is to have whatever is creating servlets first create an Injector and then request the servlets be created by the injector. If this means you'll have more than one injector, then yes, that will be a problem but only for the objects you want to be singletons. So you could make a factory pattern class for a singleton injector, or you could find where these classes (here typed bar) which are creating servlets themselves are created (in foo), and then start with the injector there (in foo) using one Guice injector to create those (bar type) classes and also modifying them (bar type) to request a provider for the servlets which they'll use instead of making calls for a new servlet.

Now that I think about this, it could be simple if it kind of only happens once or twice for 10-20 servlet types, or it could be complicated if there's some framework that defines totally flexible behavior for what gets newed up when and why.

Another option would be avoiding @Inject on fields at all times, as recommended. So now your servlets are taking in an org.slf4j.Logger as a construction parameter. The constructor is marked @Inject, and it assigns the parameter's value to the field. Then any place you're not using injection should break with an incorrect number of parameters at a new call. Fix these by figuring out how to either get the servlet provided here instead, or how to get a provider for the servlet into the class.

Not sure what you mean... if you inject objects in to your servlets/filters, those objects have their dependencies injected by Guice as well, and so on all the way down.

How are you creating the classes that you're trying to inject this logger in to? They must be created by Guice to be injected, which means no new.