revisiting @ImplementedBy

[Henning Schmiedehausen <he...@schmiedehausen.org>]

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

Re: revisiting @ImplementedBy

[Gagandeep singh <ga...@gmail.com>]

Maybe you should vote a +1
here<http://code.google.com/p/google-guice/issues/detail?id=500#c2>
 :)

On Fri, Aug 6, 2010 at 5:25 AM, Henry Saputra <he...@gmail.com>wrote:

> Hi Henning,
>
> Any update about the code review for this proposal?
>
> - Henry
>
> On Wed, Jun 16, 2010 at 11:11 AM, Henning Schmiedehausen <
> henning@schmiedehausen.org> 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
> >
>

Re: revisiting @ImplementedBy

[John Hjelmstad <fa...@google.com>]

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 <he...@gmail.com>wrote:

> Hi Henning,
>
> Any update about the code review for this proposal?
>
> - Henry
>
> On Wed, Jun 16, 2010 at 11:11 AM, Henning Schmiedehausen <
> henning@schmiedehausen.org> 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
> >
>

Re: revisiting @ImplementedBy

[Henry Saputra <he...@gmail.com>]

Hi Henning,

Any update about the code review for this proposal?

- Henry

On Wed, Jun 16, 2010 at 11:11 AM, Henning Schmiedehausen <
henning@schmiedehausen.org> 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
>