Binding different database sessions to different backends.

[Kevin Burton]

I can't find a decent way to do this and none of them pass my "smell
test"..

Basically we have a few Provider<Client> instances that each represent
their own Elastisearch cluster.

We are decoupling our Elasticsearch clusters ... so we can no longer use a
single Provider<Client>.

The problem is that I have a bunch of code written to use inject
Provider<Client>

I guess what I want to do is have specific components use specific
Provider<Client> automatically within the same binding.

Is there a way I can do this without having to use a different
injector/modules?

I can't think of an elegant way but maybe there's some Guice mojo I'm
missing.

[Tim Boudreau]

I worked on a project once that had a similar requirement - in my case it
was a codebase littered with code to load legacy properties files,
scattered throughout it, and I wanted to get that code out of the business
of reading files and having to know where they were, and use @Named for the
property values. So I needed a way to annotate different packages with the
name of what they needed to load.

I don't know if I'd do it again like this, but the solution was this
feature of Giulius, a micro-framework on top of Guice for loading settings
and application lifecycle:
https://github.com/timboudreau/giulius#using-namespaces-with-settings

Essentially how it works is:
- A runtime annotation on classes or packages identifies which "namespace"
(in your case, a name that specifies which back end) to use
- An annotation processor puts a flat list of all known names used for
that into META-INF, which is used when setting up bindings
- A custom Provider will provide the Properties (or in your case, the
Client)
- A ProvisionListener wraps the call to actually do injection - when
called it
- Looks up the class being instantiated
- Looks for the annotation on the class
- If not present, looks for the annotation on the package and all
parent packages, failing over to a default if none present
- Sets a ThreadLocal with the current "namespace" or "context"
(important: this can be called reentrantly, so save the old value of the
ThreadLocal and restore it after provisioning)
- The custom Provider looks in the ThreadLocal and provides a different
object depending on what it contains

https://github.com/timboudreau/giulius/blob/master/giulius/src/main/java/com/mastfrog/giulius/Dependencies.java#L626

Hope that provides some inspiration,

Tim