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." <jc...@mitre.org> To: "dev@shindig.apache.org" <dev@shindig.apache.org>, Date: 11/02/2011 01:04 Subject: RE: Injecting global config contributors for the default config process >-----Original Message----- >From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >Sent: Monday, October 31, 2011 2:26 PM >To: dev@shindig.apache.org >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." <jc...@mitre.org> >To: "dev@shindig.apache.org" <dev@shindig.apache.org>, >Date: 10/31/2011 12:30 >Subject: RE: Injecting global config contributors for the default >config process > > > >>-----Original Message----- >>From: Stanton Sievers [mailto:ssiev...@us.ibm.com] >>Sent: Monday, October 31, 2011 8:12 AM >>To: dev@shindig.apache.org >>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 > > >
