On Thu, Dec 4, 2008 at 9:13 AM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> If we drop @ImplementedBy and stick with Guice 1.0 then we should at least
> provide a way to override the default bindings that's easier than
> duplicating entire modules and document this technique.
>
>
> One way would be to implement the default modules with a configure() method
> like this:
>
> configure(Set<Class> override) {
> if (!override.contains(Person.class)) {
> // bind Person
> }
> ...
> }
That's pretty scary. I'd rather leave @ImplementedBy or upgrade to Guice 2.0
(even though it's not 'official' yet).
>
>
> Then implementers can create their own module like this:
>
> class MyShindigModule extends DefaultShindigModule {
> private static final Set<Class> overridden = Sets.newHashSet(....);
> public configure() {
> super.configure(overridden);
> // my bindings go here.
> }
> ...
> }
>
>
> This insures we don't violate the DRY prinicple and also insures that all
> implementations go through the DefaultShindigModule, which would be a good
> thing. This type of pattern is already present for the PropertiesModule and
> is actually pretty useful.
>
>
>
>
> On Dec 4, 2008, at 8:59 AM, Louis Ryan wrote:
>
> If people object to @ImplementedBy then its clearly not a big deal to
>> remove
>> it but the truth is that the equivalent will be moved into module specific
>> default configurations which implementers can override. We will continue
>> to
>> have a default guice module in common, gadgets & social packages because
>> gadgets and social are designed to run as separate components.
>>
>> So in short Im OK with dropping the use of @ImplementedBy to more clearly
>> document the code. The guice module used in SampleContainer should be an
>> example to developers how to override the default module configurations.
>> Perhaps moving some of it out of web.xml might make things more obvious
>>
>>
>>
>> On Wed, Dec 3, 2008 at 11:34 PM, Ben Smith <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>> On 4 Dec 2008, at 00:29, Henning P. Schmiedehausen wrote:
>>>
>>> Adam Winer <[EMAIL PROTECTED]> writes:
>>>
>>>>
>>>> On Wed, Dec 3, 2008 at 2:12 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>
>>>>>
>>>> SocialApiGuiceModule is never usable for production, and it can't be for
>>>>
>>>>> the
>>>>>> simple fact that there's no way to reason about the data store of a
>>>>>> given
>>>>>> container.
>>>>>>
>>>>>>
>>>>> There's no reason we can't provide a Module that implements the parts
>>>>
>>>>> that have sane default bindings. And putting the sample container
>>>>> dependencies in a module in o.a.s.social.core.config is way wrong.
>>>>> Ditto the abuse of @ImplementedBy to tie PersonService, etc. to the
>>>>> JsonDbOpensocialService. All that should be in a separate
>>>>> SampleContainerModule to make it crystal clear to developers the
>>>>> interfaces they absolutely have to bind for a real, production
>>>>> container.
>>>>>
>>>>>
>>>> +1.
>>>>
>>>>
>>> This was all very confusing when I recently started working on Shindig,
>>> especially as I had never used Guice before.
>>>
>>> I agree that something like a SampleContainerModule would help clarify
>>> what
>>> is going on and what you need to do to integrate Shindig with your
>>> production environment. I am all for convention over configuration but
>>> @Implemented By doesn't provide this, so it just ends up being confusing
>>> wizardry.
>>>
>>> Additionally, up-to-date and easy-to-find documentation on what you
>>> should
>>> inject, how and why would really help. I'd be happy to work on this..
>>>
>>> Cheers,
>>> Ben Smith
>>> BBC
>>>
>>>
>>>
> Paul Lindner
> [EMAIL PROTECTED]
>
>
>
>
