Overriding Guice module already installed by child

[praveen kumar]

Suppose I have a package that depends on two other packages that are like target packages. This is how my dependency tree looks

X->Y->A
X->Z->A

Now Both Y and Z are like target packages already and they install A's module as a part of their Guice module. So when I am trying to install the module of Y and Z from my package X am facing with errors that the binding for certain types has already been configured. I somehow feel that to force bind A's module as a part of the installation of Y and Z is wrong (it beats the idea of plugging in different implementations that I want - assert me on this) and the modules have to be scanned at an environment (that has the whole list of package version set instances deployed) scope. But given that I do not have a control over the package Y and Z (its third party) is there a way I can solve this problem ? I read through the Guice deduplication and it does not work. I am currently using Guice 3.0.

[Nate Bauernfeind]

Here's a short answer solution that should solve your problem, but it results in two separate object-graphs as defined by A:

Y and Z should probably be private modules and they should only expose the things that are being used. Being that they are third party, then I strongly recommend creating a Y' and a Z' that are PrivateModules that install Y and Z respectively and expose only the pieces that you need available in X (or that you want X to expose).

Here's my opinion:

I just recently had to traverse through some code that uses this pattern and I have to say that I hate it. Guice is really good at helping you breakdown your problem space to avoid worrying about dependencies. And here you are, worrying about your dependencies ;) (and it's not even your fault!). I've always preferred to separate my modules and combine them only at one place; the injector creation site. It's nice to free some of the responsibilities and give them to guice. If there are any missing dependencies (oops I forgot to include module 'A') you should find out immediately at runtime (there are circumstances when you won't, but not everyone deals with child injectors and the like). Guice's philosophy is fail fast whenever possible. I really like being able to remove a module and swap it with a completely different component implementation; which is what your intuition is telling you anyways!

Now if someone wanted to somehow represent module dependencies, I would probably recommend to do it by exposing the list of module classes that are dependencies and then let when about to create the guice injector make sure that the dependencies are covered. Maybe by just taking the modules, construct a set of dependent module classes and then make sure each dependencies is in the original module list. Or something like that. Realistically, anything is better than installing a dependency like that ;).

Good luck,

Nate

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.