Yes, singletons are local to the injector object. There's some more
advanced features of Guice which can allow multiple singletons in an
injector (using a child
injector<http://google-guice.googlecode.com/git/javadoc/com/google/inject/Injector.html#createChildInjector(com.google.inject.Module...)>
or private
module<http://google-guice.googlecode.com/git/javadoc/com/google/inject/PrivateModule.html>)...
but for the basics, those aren't important.
The "best practice" way of organizing a program using Guice is to have one
module per "component". Typically that breaks down to one module per
package. A component's module would have bindings just for that component,
and a top-level Module at the very top of your program would have a module
that installs all its component's modules.
You could imagine a set of components like:
persistence/jpa: JpaPersistenceModule
persistence/jdo: JdoPersistenceModule
network/netty: NettyNetworkModule
network/mina: MinaNetworkModule
ui/widgets: WidgetModule
....
There's multiple options for persistence and/or network, and your top-level
module would be something like:
class MyAppModule extends AbstractModule {
public void configure() {
install(new JpaPersistenceModule());
install(new MinaNetworkModule());
install(new WidgetModule());
...
}
}
In the above example, the app picked jpa & mina as the respective
persistence & network implementations, and also installed the widget
component. Here's an
example<https://github.com/wiregit/wirecode/blob/master/components/gnutella-core/src/main/java/com/limegroup/gnutella/LimeWireCoreModule.java>back
from my LimeWire days of a top-level module that installed a bunch of
components (note: it's old and probably doesn't compile anymore).
The general idea is that you want each component to only have a module that
binds what that component is *providing*, not what that component
*requires*. Otherwise, you get into a scenario similar to "dll hell",
where modules overlap each other in requirements & things are bound
multiple times in slightly different ways, causing all sorts of problems.
Most "libraries" would be better integrated into an app by exposing a
Module that the app's author can install. This way the app can @Inject one
of the library's classes, and the app author doesn't need to worry about
the implementation details of how that class was created or what it depends
on.
That said, some libraries may also want to take the approach of just using
an injector internally within themselves for managing their dependencies.
Those kinds of libraries are taking a bit more of an IPC/RPC approach --
you're not really integrating the library into your app so much as you're
asking the library to do some things and then getting the results back.
sam
On Fri, Jan 3, 2014 at 10:12 PM, Ian Clarke <[email protected]> wrote:
> Ok so, to put it another way (and tell me if I'm wrong), singletons are
> local to the injector object?
>
> So if I have an class X that creates its own injector per-instance, and
> that injector contains singletons, I can safely create multiple instances
> of X?
>
> I hope that's true because it makes sense, and it would be tough to use
> Guice within libraries otherwise.
>
> Ian.
>
> On Friday, January 3, 2014 3:59:11 PM UTC-6, Sam Berlin wrote:
>
>> Hey Ian --
>>
>> Singletons are global per the injector that created then. That's neither
>> per module nor per JVM -- rather, it's per the collection of modules that
>> build up the Injector.
>>
>> sam
>>
>>
>> On Fri, Jan 3, 2014 at 4:48 PM, Ian Clarke <[email protected]> wrote:
>>
>>> I've been thinking about how to use Guice within a library, but realized
>>> that singletons might pose a problem here if they are global to a JVM.
>>>
>>> My hope is that objects declared with scope SINGLETON are local either
>>> to a module, or an instance of Injector. Is this the case?
>>>
>>> Ian.
>>>
>>> --
>>> 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 [email protected].
>>> To post to this group, send email to [email protected].
>>>
>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/groups/opt_out.
