[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: Text File MAGNOLIA-6027.patch    
Issue Links:
causality
is causing MAGNOLIA-6538 Improve support IoC multi-binding Accepted
dependency
is depended upon by MAGNOLIA-6076 Make config by file optional Closed
is depended upon by MAGNOLIA-6086 Registry/RegistryFacade API - propose... Closed
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.
However, this Guice extension allows it: https://github.com/google/guice/wiki/Multibindings

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

Generated at Mon Feb 12 04:10:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.