On Thu, Dec 4, 2008 at 10:41 AM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> 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).
Agreed, that's scary - building an override architecture to stretch us
the short time before Guice 2.0 is out makes little sense.
@ImplementedBy is the best of all alternatives for now, but I'm happy
to kill it when 2.0 is out if there's strong opinion against it.
>
>
>>
>>
>> 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]
>>
>>
>>
>>
>
