Feature Request: Expose List of Provider<T>

[LeDominik]

Caveat: I have no idea how much work this is 😄

I'd like to propose to provide some facility to get all the (currently private Provider<T>) providers that a component has via some sort of API / Set-Injection / whatever is idiomatic... The background is that while I ❤️ how Dagger 2 operates, it's a bit hard to bridge into dynamic frameworks.

Case in point: Jersey 2 (in Dropwizard) with Dagger 2:

• Dropwizard doesn't prescribe any DI, so Dagger 2 is just perfect, however there's JAX-RS (implemented by Jersey) from which you typically want to reach out into your own Dagger powered (business) logic
• Jersey 2 uses HK2: Now that leads JAX-RS resource-classes being treated by HK2/Jersey (which knows about awesome (dynamic runtime) things like HTTP-Headers with @Context) but of course not about Dagger-managed stuff
• If combined nicely then one sticks to constructor injection via Dagger and the rest (which is then basically just boilerplate and no logic) of the JAX-RS resource is owned by HK2 -- see e.g. @HunterSherms comment at Dependency Injection frameworks dropwizard/dropwizard#1626 (comment)
• However it would be pretty easy to give HK2 knowledge about Dagger 2 Providers via e.g. Jersey's AbstractBinder as demonstrated in this Gist

I think that #413 is really about a similar thing (I'm not a Guice guy). My Spring is not 100% up-to-date but programmatically getting this into the ApplicationContext isn't difficult either.

But we'd need programmatic access to the Provider's somehow -- and they are all in (or reachable through) the Component implementations (at least as far as I can observe in my generated code). And I honestly believe this should not require another separately versioned generator like Bullet.

[tbroyer]

Somewhat related: https://java.net/jira/browse/JERSEY-1933

From my limited experience with Jersey, you're better off using HK2, possibly bridging your Dagger modules (possibly through Guice: HK2-Guice integration and Guice-Dagger adapter), but not components.

[LeDominik]

@tbroyer -- you're right (generalized title); it's actually the modules, I just happened to discover everything neatly lined up at the generated component classes.

[gk5885]

The short answer is that we won't be supporting this.

One of the primary advantages of compile-time DI is that you aren't actually tied to supporting all permutations of injection sites (an instance, a Provider, a Lazy, whatever) for every single binding because you know statically which will be requested. One of our goals for the next few months is to take advantage of that fact more than we have ever done before to really reduce the size of generated components. The consequence is that while we have a Provider for pretty much every binding today, that is almost certainly not going to be true in the future.

That said, while it hasn't been our focus, we would love to see a good http server solution with Dagger. We use Dagger on the server within Google, but it is very strongly tied to our custom serving stack. Something that worked with an open-source stack would be great, and we'll gladly help support it, but this particular request is so strongly at odds with our other efforts that it doesn't seem like a feasible path forward.

[LeDominik]

@gk5885 thanks for the background, understand the roadmap better now, thanks! Then it doesn't make any sense to invest time into that bridging exercise -- maybe I can find a nice REST server-thing that doesn't come with a full DI framework...till then I'm sticking to my current strategy.