[MAGNOLIA-6027] IoC: Support multi-binding Created: 19/Dec/14 Updated: 09/Feb/16 Resolved: 05/Mar/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | None |
| Fix Version/s: | 5.4 |
| Type: | New Feature | Priority: | Neutral |
| Reporter: | Magnolia International | Assignee: | Magnolia International |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | guice, ioc | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Sprint: | 5.4 Sprint 1 | ||||||||||||||||||||
| Description |
|
Currently, we can't @Inject multiple implementations of a common type, e.g.:
@Inject
public SomeClientCode(Collection<Foo> allFoos) {
This is because Guice forces us to give a binding "key" to all components we register. We still have to "key" those bindings though. One still can't inject "collection of some arbitrary type", unless "arbitrary type" as been bound via multi-bindings. One way we could achieve this, is by annotating the types we want to "multi-bind"; at registration time, we look if the component we're registering has this annotation (directly or via its sub-types), and create multi-bindings for the type that has the annotations. Here's a patch that does this Use case: registries and callbacks. We have a bunch of places where components explicitly register themselves to make themselves known to others because of this. Concrete use-case: with new configuration mechanisms in 5.4, we'll have a "registry of registries" component, which needs to know about all registries in the system. With this feature, we don't need to invent a terse callback mechanism, and can't instead proceed on the "don't call us we'll call you" pattern that IoC is supposed to promote. PS: I'm not entirely sure about the scoping of those components, and it's currently lacking any other test than "i've tried it in a live system and it worked". PPS: Scope seems to work as expected - which may make things tricky (if "client" is not lazy-singleton, and one of the impls is lazy, it won't see it) |
| Comments |
| Comment by Magnolia International [ 19/Dec/14 ] |
|
With this impl, one unfortunately has to inject a Set<type>, I was hoping a simple Collection<type> would work |
| Comment by Magnolia International [ 18/Feb/15 ] |
|
Starting work on feature/guice-multibinding |
| Comment by Magnolia International [ 18/Feb/15 ] |
|
Currently having an issue related to https://github.com/google/guice/issues/791 (because we don't necessarily bind a component's implementation with the implementation as a key) |
| Comment by Magnolia International [ 25/Feb/15 ] |
|
pushed a fix for the scope issue on feature/guice-multibinding-2 branch. I'm not too convinced. Hopefully the Guice people comes up with a better explanation. |
| Comment by Magnolia International [ 26/Feb/15 ] |
|
After some reflection, I guess the worse that could happen with the extra binding, is that we already have a binding for FooImpl elsewhere, which seems like a nasty idea to begin with. Unfortunately, we can't prevent it or check for it (the 2nd binding for FooImpl might happen later / in a different module) |
| Comment by Magnolia International [ 05/Mar/15 ] |
|
With help from tmattsson, a better fix is now on feature/guice-multibinding-3 |