2c: I've never been a huge fan of ImplementedBy anyway. Default users will get DefaultGuiceModule bindings, and "informed"/customizing users presumably ought to be aware of their bindings, even if it's modestly annoying to find missing bindings at first.
--j On Thu, Aug 5, 2010 at 4:55 PM, Henry Saputra <[email protected]>wrote: > Hi Henning, > > Any update about the code review for this proposal? > > - Henry > > On Wed, Jun 16, 2010 at 11:11 AM, Henning Schmiedehausen < > [email protected]> wrote: > > > Hi, > > > > with the release of Guice 2.0 (and our adoption), the need for "soft > > bindings" of Interfaces that can be easily overridden has somewhat > > diminished. But our current usage of @ImplementedBy introduces some > > friction when you try to integrate Shindig into an environment where > > lots of the existing interfaces need to be overridden. Mostly because > > a missing explicit binding will not result in an instant startup error > > but in a default implementation being bound instead of the customized > > class. > > > > In my case, I hook CacheProvider into our internal caching > > infrastructure using a custom implementation. However, the code broken > > in one place for hard to track down reasons until I figured out that > > this specific piece was missing the custom Guice binding and fell back > > to LruCacheProvider which did not do what I expected it to do. > > > > In our custom Shindig tree, I now have a set of patches that remove > > all @ImplementedBy annotations and replaces them with explicit > > bindings in Guice modules. How controversial would be applying this > > patch? Apache JIRA seems to be down right now, so I can't file a JIRA > > right away. > > > > -h > > >
