13

I want to conduct a chain of processing elements and wire them together via Guice. Let's assume the following path:

  • interface A implemented by class AImpl needs some input
  • interface B implemented by class BImpl needs A
  • interface C implemented by class CImpl needs B
  • interface D implemented by class DImpl needs C

The dependency of A can only be resolved at runtime and not at configuration time. The usual approach would be to use Assisted Injection in this case to create a factory, that takes the missing instances as parameters, just like this:

public interface AFactory { public A createA(String input); }

But what I actually want is something like this:

public interface DFactory { public D createD(String inputForA); }

I don't want to manually pass AImpl-specific dependencies through the whole hierarchy. Is it possible to achieve this with Guice? If not, what's the best way to circumvent this problem elegantly while still retaining benefits of injection?

Improve this question

2 Answers 2

Reset to default
7

Cheating way: Stick input in a static variable or singleton ThreadLocal. Set it before your pipeline starts and clear it after it ends. Bind everything else through DI.

Fancy way: In A, refer to a @PipelineInput String inputString but don't bind it in your main injector. Otherwise, bind dependencies as you normally would, including referring to @PipelineInput in other pipeline-related classes. When you do need a D, get it from your implementation of a DFactory, which I'm calling PipelineRunner.

public class PipelineRunner { @Inject Injector injector; // rarely a good idea, but necessary here public D createD(final String inputForA) { Module module = new AbstractModule() { @Override public void configure() { bindConstant(inputForA).annotatedWith(PipelineInput.class); } }; return injector.createChildInjector(new PipelineModule(), module) .getInstance(D.class); } }

Naturally, binding attempts for A, B, C, and D will fail outside of PipelineRunner for lack of a @PipelineInput String--you'll get a CreationException when you create the injector with those unsatisfied dependencies, as you discovered--but those pipeline-based dependencies should be easy to separate into a Module that you install into the child injector.

If this feels too hacky, remember that PrivateModules are also "implemented using parent injectors", and that the whole point of dependency injection is to make a dependency like inputForA available to the whole object graph in a decoupled way.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

I have to recall my approval, beacuse of this: "injection attempts for A, B, C, and D will fail outside of PipelineRunner for lack of a @PipelineInput String" This doesn't work, because Guice verifies Injectors at configuration time and fail as soon as it detects an unsatisfied binding, which is why you cannot create an almost complete Injector, that will be completed by its child. Private Modules overcome this by using a special binder.
My mistake; you do have to bind A, B, C, and D adjacent to the constant. Trivial to fix, though. Answer updated.
Okay, so I have to bind everything that's related to the pipeline exclusively inside the child injector and the parent injector only knows about the factory ("PipelineRunner").
That's right. The child injector classes can refer to things bound in the parent injector, of course.
1

I see three options. They depend on how often you change the input for A .

1) Bind input as a constant in your module. This works only, if you know that value before you create the Injector and never want to change the value. See bindConstant

2) Use a private submodule which binds either A or the value for input inside that module. Basically you can have two or three instance graphs with different value. See newPrivateBinder.

3) Use a Scope ala RequestScope, SessionScope, ... This way you can change the input often but you must enter/leave the scope at some point to be defined. See Custom Scopes for an example.

Improve this answer

1 Comment

1) is too late and 2) is just a special case of 1). I also thought about scopes, but that's so much boilerplate for such a small problem that I'd rather leave out DI altogether for elegancy's sake :-/

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.