Hi Henry, I don't think I have a particular scenario for global contributors. I was simply playing around with the code to further my understanding. As part of that I ran into this problem.
Thanks, -Stanton From: Henry Saputra <[email protected]> To: [email protected], Date: 11/02/2011 14:17 Subject: Re: Injecting global config contributors for the default config process Hi Stanton, I dont think the order of the contributors is necessary here so change it to Set should be fine. What scenario you have in mind to do this? - Henry On Wed, Nov 2, 2011 at 4:09 AM, Stanton Sievers <[email protected]> wrote: > Thanks for finding that thread. That is the exact problem I'm running > into. As the thread suggests and as I've confirmed with some simple > testing, annotations solve the problem. > > -Stanton > > > > From: "Ciancetta, Jesse E." <[email protected]> > To: "[email protected]" <[email protected]>, > Date: 11/02/2011 01:04 > Subject: RE: Injecting global config contributors for the default > config process > > > >>-----Original Message----- >>From: Stanton Sievers [mailto:[email protected]] >>Sent: Monday, October 31, 2011 2:26 PM >>To: [email protected] >>Subject: RE: Injecting global config contributors for the default config > process >> >>I just noticed one caveat with using the Multibinder. I'm doing this: >> >> Multibinder<ConfigContributor> configBinder = > Multibinder.newSetBinder >>(binder(), ConfigContributor.class); >> configBinder.addBinding().to(GlobalConfigContributor.class); >> >>Now in DefaultConfigProcessor.setGlobalContributors, I'm getting the >>GlobalConfigContributor class I've bound here as well as all of the > values >>of the MapBinder for String->ConfigContributor that is bound in the >>DefaultConfigContributorModule. I have to add an Annotation when I do >>Multibinder.newSetBinder to keep that from happening. This doesn't > happen >>when I remove my Multibinder and only have the MapBinder... odd. It's >>like the MapBinder values are getting added to the Multibinder config >>automatically. > > It sounds like this might be a bug in Guice -- I found this thread on the > Guice discussion board which sounds similar to what you're describing: > > http://groups.google.com/group/google-guice/browse_thread/thread/934e30b7ed0da98f > > >>Maybe that's why the original code is a List instead of a Set that uses >>Multibinder. >> >>-Stanton >> >> >> >>From: "Ciancetta, Jesse E." <[email protected]> >>To: "[email protected]" <[email protected]>, >>Date: 10/31/2011 12:30 >>Subject: RE: Injecting global config contributors for the default >>config process >> >> >> >>>-----Original Message----- >>>From: Stanton Sievers [mailto:[email protected]] >>>Sent: Monday, October 31, 2011 8:12 AM >>>To: [email protected] >>>Subject: Injecting global config contributors for the default config >>process >>> >>>Hi everyone, >>> >>>I've recently been looking at the ConfigContributor and ConfigProcessor >>>code and the workflow for getting configuration code the JavaScript side >>>of things. In DefaultConfigProcessor there is a setGlobalContributors >>>method that is injectable and takes a List<ConfigContributor> as a >>>parameter. How is this injectable via Guice? I thought it could be > done >>>with Multibinder but that only seems to allow Set contributions. What > is >>>the intended way to contribute a List<ConfigContributor> (or any List > for >>>that matter) with Guice? >> >>It looks like you can use a TypeLiteral to do this: >> >>http://code.google.com/p/google-guice/wiki/FrequentlyAskedQuestions >> >>And if you search the Shindig codebase for usages of TypeLiteral you'll >>find a few examples of where it is indeed being used to setup List's for >>Guice injection. >> >>However this doesn't seem as flexible as using a Multibinder with a Set >>though since with Multibinder it seems you can append to the Set across >>any number of different Guice modules, and with the TypeLiteral approach > I >>don't think that's possible. >> >>I'm far from a Guice expert though so if someone has a better solution >>please chime in. >> >>>I found this issue, however, the solution seems to be Multibinder. :) >>>http://code.google.com/p/google-guice/issues/detail?id=37&can=2&q= >>> >>>If there's no good way to do this, I propose changing >>>setGlobalContributors to take a Set<ConfigContributor> so that >>Multibinder >>>can be used. I don't think order or duplicate entries really matter for >>>this use case, so I don't see why a Set wouldn't work.... >> >>Even though there does seem to be a workaround available I don't see any >>reason why this shouldn't be a Set -- and by making it a Set we can use >>Multibinder and gain the additional flexibility that buys us in terms of >>being able to add to the bindings across multiple Guice modules. >> >>>Thanks, >>>-Stanton >> >> >> > > > > >
