Well, the scenario is a simple service-interface that returns a JSON
array to configure a Javascript component. And depending on the input,
the content of the JSON array looks different, that's why there are
multiple implementations. Usually we iterate over the implementations
and take the first result that is not null - and I just noticed that's
exactly what the ChainBuilder does! It hides quite a bunch and does
'magic' :/ but I'll give it a try. I think Lances pointer to the
OrderedConfiguration looks quite useful, too and is basically the key
- I'll see what plays out best.
However, with the given options it's a little more overhead to
"hand-craft" the implementations to build the configuration but this
should be do-able. Though think it would be more intuitive to just
have the List<> injected from whatever is registered with the Binder.
Thanks,
Michael
On Tue, Jun 17, 2014 at 8:51 PM, Lance Java <lance.j...@googlemail.com> wrote:
> I tend to do the following:
>
> public interface FooProvider {
> List<Foo> getFoos();
> }
>
> @UsesOrderedConfiguration(Foo.class)
> public class FooProviderImpl implements FooProvider {
> private final List<Foo> foos;
> public FooProviderImpl(List<Foo> foos) { this.foos = foos; }
> public List<Foo> getFoos() { return foos; }
> }
>
> Then you can @Contribute to the FooProvider to add to the list and @Inject
> the FooProvider wherever you need the list.
>
>
>
> On 17 June 2014 18:21, Thiago H de Paula Figueiredo <thiag...@gmail.com>
> wrote:
>
>> On Tue, 17 Jun 2014 09:54:24 -0300, Michael Leuthold <
>> michael.leuth...@gmail.com> wrote:
>>
>> Hello,
>>>
>>> I am currently stuck with the following problem: I try to inject a
>>> list of implementations of a certain interface but it seems it does
>>> not work using the straight approach of injecting a
>>> "List<SomeInterface> impls"
>>>
>>> Though implementations exist and a list is injected but it's just
>>> empty. Does anyone have a hint where to look here? Maybe I need to
>>> register that list explicitly.
>>>
>>
>> Tapestry-IoC doesn't support that, at least not yet. What's your scenario?
>> Usually, when we need more than one implementation of a given interface, we
>> create a pipeline (http://tapestry.apache.org/pipelinebuilder-service.html)
>> or chain (http://tapestry.apache.org/chainbuilder-service.html) to
>> consolidate all these implementations as a single service. Or you can
>> create a service that receives these service implementations as its
>> distributed configuration and acts as a locator for it.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
