Hey Gagandeep, Thank you, it seems your solution is cool thing with more flexibility.
What I am asking is to *append* a rewriter to current rewriters list from DefaultGuiceModule, b/c I think the existing rewriters are good enough for my case. And as I know, DefaultGuiceModule does a lot of things (installing different modules etc), but not only install RewriterModule for binding rewiters. So I think replace DefaultGuiceModule with custom module class in web.xml maybe not enough, you still need to do other same work as DefaultGuiceModule in your module.Please note that RewriterModule installed in DefaultGuiceModule is not configured in web.xml. Any comments? Thanks a lot. Thanks, Kevin Zhang (凯峰) Gtalk: [email protected] Blog: http://www.zhangkf.com Twitter: http://twitter.com/zhangkf On Sat, Oct 30, 2010 at 10:28 AM, Gagandeep singh <[email protected]>wrote: > Hi Kai, Paul > > You are both right :) The order of rewriters matters. > > I have a patch< > http://codereview.appspot.com/2058042/diff/123001/java/gadgets/src/main/java/org/apache/shindig/gadgets/rewrite/RewriteModule.java > > > (which > JohnH has been reviewing and providing ideas for) which does something > similar. The idea is, we create a map binder from container + flow id -> * > provider* of list of rewriters. > And we provide the list of rewriters similarly to how we providing > currently. Since we add provider of rewriter list, we can provide a > different list without having to add it to the map binder separately (map > binder will cry if you add same key twice). > Any new binding can be added to map binder in the custom module. > > The way ppl can override this is, in your new module, you again provide a > new list of rewriters. And then you override the DefaultGuiceModule with > your module. > > Say you were providing a default list of GadgetRewriters in > DefaultGuiceModule: > @Named("gadget.rewriters") List<GadgetRewriter> provideDef(Rewriter1 r1) { > } > > and you want to change this list of provide Rewriter2 as well. You create > your module called MyModule and provide: > @Named("gadget.rewriters") List<GadgetRewriter> provideDef(Rewriter1 r1, > Rewriter2 r2) { > } > > And then early on in the code, you override default guice module with your > module: > Modules.override(new GuiceModule()).with(new MyModule()); > > I think your facing the problem because maybe web.xml does not allow you to > override a module with a new one. And when 2 modules provide same binding, > guice dies. > A quick solution for your case would be to change web.xml to provide your > module in place of DefaultGuiceModule, and change your module to > install DefaultGuiceModule after overriding it with your rewriter list. > Something like: > > web.xml: > <context-param> > <param-name>guice-modules</param-name> > <param-value> > org.apache.shindig.common.PropertiesModule: > org.apache.shindig.gadgets.*MyGuiceModule*: > org.apache.shindig.social.core.config.SocialApiGuiceModule: > ...... > > MyGuiceModule.java: > protected void configure() { > Modules.override(new DefaultGuiceModule()).with(new AbstractModule() { > protected void configure() { > } > @Provides @Named("gadget.rewriters") List<GadgetRewriter> > .... > } > } > > I hope im making sense. > > On Fri, Oct 29, 2010 at 5:52 PM, Paul Lindner <[email protected]> wrote: > > > I think this is a good idea, however I'm concerned that the ordering of > > Rewriters may be important. > > > > I'm guessing that we could make a SortedSet if we had a Comparable<> > > implementation of all rewriters. > > > > On Fri, Oct 29, 2010 at 1:23 AM, Kai Feng Zhang <[email protected]> > > wrote: > > > > > I found a possible solution to extend Shindig rewriter capability, > using > > > multibinding in Guice. > > > > > > Please see: > > > > > > > > > http://google-guice.googlecode.com/svn/trunk/latest-javadoc/com/google/inject/multibindings/Multibinder.html > > > > > > I created a jira for this, see > > > https://issues.apache.org/jira/browse/SHINDIG-1456 > > > > > > > > > > > > On Fri, Oct 29, 2010 at 3:02 PM, Kai Feng Zhang <[email protected]> > > > wrote: > > > > > > > Hi, > > > > > > > > I'd like to add a custom rewriter into Shindig, with requirement of > no > > > need > > > > to change Shindig rendering gadget server side code directly. I want > to > > > add > > > > it as a new feature in extras, so when this feature is required by > > > gadget, > > > > the custom rewriter will do some special work when rendering gadget > at > > > > server side. > > > > > > > > But I checked Shindig code, RewriteModule @Provides all predefined > > > > rewriters with @Named("shindig.rewriters.gadget") , and > > > > then GadgetRewritersProvider will provide all rewriters as per the > same > > > > @Name when rendering gadget. > > > > > > > > If I create a new Module in shindig extras, and @Provides custom > > rewriter > > > > with same @Name, and startup server, there will be error saying the > > same > > > > @Name is configured already by RewriteModule. > > > > > > > > Can anyone please help if there is some way to append such a rewriter > > > > without touching any existing Shindig gadget rendering code? Or that > is > > > the > > > > only way to extend a new rewriter for gadget rendering? > > > > > > > > Thanks a lot! > > > > > > > > > > > > > > > -- > > Paul Lindner -- [email protected] -- linkedin.com/in/plindner > > >
