Binding Listeners Patch

[GoogleCodeExporter]

Created a separate issue for binding listeners, as it's not necessarily the
same as issue 38 (where the prior patch is at).

This is a framework (modeled after the type listener framework) for adding
arbitrary binding listeners that are notified when a new binding is
available.  The patch also converts eager singleton listeners to using the
framework.  This solves the following issues:

* JIT eager singleton bindings discovered after Injector creation were not
eagerly created.  (no current issue id for this)
* JIT eager singleton bindings from any child injector were not eagerly
created. (issue 386)
* Allows users to develop their own strategies for eager singletons (using
different singleton scopes, for instance). (issue 38)

An outstanding issue that Alen pointed (in issue 38) is "using a
PrivateModule with expose the exposed binding will get heard 2 times."

Original issue reported on code.google.com by sberlin on 12 Jun 2009 at 3:51

Attachments:

• binding-listeners.txt

[GoogleCodeExporter]

FYI Sam, I'm contemplating addressing these problems in a different way. We 
were thinking about supporting 
user-supplied implementations for @Singleton. 

Although I do think this is a pretty cool idea. Aside from the singleton 
issues, are there other applications?

Original comment by limpbizkit on 22 Jun 2009 at 2:27

• Added labels: Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

This patch also fixes issue 386, which isn't strictly related to user-supplied
singletons.  In general, the patch solves all issues with late-found JIT 
singletons
not being eager (including the Injector.getProvider(MySingletonObject.class) not
eagerly creating MySingletonObject issue).

issue 386 is a particular problem for us, as I'd like to create a child 
injector (the
UI injector, based off the core injector), but right now it's essentially 
impossible
to use a child injector and have eager singletons created.  Explicitly 
declaring all
bindings in the child injector isn't an option -- it's a PITA to have to bind 
all
(even linked!) child bindings.  (FWIW, I would *love* to have a 'strict' mode 
where
JIT bindings, except linked bindings, are flatly disallowed.  This would open 
the
door a bit more to allowing child injectors [and private modules] behave as 
expected.)

Original comment by sberlin on 22 Jun 2009 at 3:58