Evan,
You'r right, I should qualify: I was suspecting that you would have
identically named properties in each of database_{one,two}.properties. If
you did, then there would be a binding clash because Guice would try to bind
different values to the same property name (also here I'm presuming their
values would be different).
e.g., Imagine you had:
db.name
in database_one.properties:
db.name = "database_one"
in database_two.properties:
db.name = "database_two"
Guice wouldn't know what to give you when you asked for "@Named("db.name")
String dbName," and that's why it doesn't allow you to have duplicate
bindings as such.
* * *
Typically, you do want one something roughly equivalent to one Module per
package. This convention goes a long way in:
1) allowing you to keep your implementation classes package private, or at
the least, their constructors package private for public classes
2) providing a convention that makes it tractable to find where the binding
exists for a given class
For (2), this is critical for a large app, lest folks be binding classes in
unpredictable locations.
So you might have:
A
/ \
B C F
/ \ / \
D E G H
As a package structure. Depending on the nature of the parent-child
relationships involved, a typical scenario will look like:
ModuleA
install module B, C, F
Module C:
install D, E
Module F:
install G, H
Then it's typically ModuleA that you will pass to Guice.createInjector().
Now this needs to be take with common sense and context of the app. Often
package structure doesn't reflect logical relationships (shit happens in the
course of coding, we all know). As such, it might not make sense for a
parent package's module to install a child package's module. Especially if
two child modules represent different implementations of the same interfaces
(e.g., fake file system and real file system). At this point, ModuleA, or
whatever your top-level server module is, will go underneath a package and
directly install one if its child modules.
* * *
Getting back to your question - the PrivateModule skirts some of
the issues of the Robot
Legs<http://code.google.com/p/google-guice/wiki/FrequentlyAskedQuestions>problem.
This allows you to install duplicate bindings which remain
entirely local to that module. As such, other modules won't see the
bindings that are not exposed through the "expose()" method.
* * *
You bring up some fundamental questions and this is dense material! Please
continue to follow-up with clarifying questions.
regards
-Fred
On Sat, Jan 29, 2011 at 7:01 PM, Evan Ruff <[email protected]> wrote:
> Hey Fred,
>
> Thanks for the suggestion. I'm not exactly sure if I'm missing something
> here, but is it possible to do something like:
>
> protected void configure() {
> Names.bindProperties(binder(), loadProperties("*
> database_one.properties*" ));
> bind(DataSource.class).annotatedWith( *@DBOne *
> ).toProvider(MySQLDataSourceProvider.class).in(Scopes.SINGLETON);
>
> Names.bindProperties(binder(), loadProperties("*
> database_two.properties*" ));
> bind(DataSource.class).annotatedWith( *@DBTwo *
> ).toProvider(MySQLDataSourceProvider.class).in(Scopes.SINGLETON);
> }
>
> In a single module? Are modules explicitly supposed to have a 1:1
> relationship between the interface/class bindings, or can you double stuff
> up based on the annotation as I have done above? Is it common or prefered to
> have a single Module for the entire configuration, or should I have a bunch
> of Singleton injectors with a number of modules, depending on things like
> property files, etc?
>
> And now, I've really confused myself... damn... thanks for the guidance!
>
> E
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-guice%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
