Ok, will do,
thanks.
Ian
2008/6/11 Kevin Brown <[EMAIL PROTECTED]>:
> On Wed, Jun 11, 2008 at 6:22 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
>
>> What is the correct way of modifying a guice module for deployers. I
>> have written a CacheProvider API that needs to be injected, but as
>> soon as I inject the default implementation, no other can be injected
>> (I only really want one deployer provided CacheProvider).
>>
>> Adding yet another Guice module to the list of modules to be loaded by
>> the injector feels like overkill, so at the moment I have
>>
>> /* Is there a better way to do this, its ugly */
>> Class<? extends CacheProvider> c = DefaultCacheProvider.class;
>> try {
>> c = (Class<? extends CacheProvider >)
>> Class.forName(properties.getProperty("cacheprovider"));
>> } catch ( Exception ex ) {
>>
>> }
>> bind(CacheProvider.class).to(c).in(Scopes.SINGLETON);
>
>
> It's probably best to just include a guice module for each of the
> implementations and then add that module to the list of modules to load in
> web.xml. The total amount of configuration for a "typical" end user is
> identical -- it's just putting a Module into the config file instead of
> directly placing a CacheProvider.
>
> This requires moving the default cache bindings, of course, but that's fine.
>
>
> There's a pretty good section on using this pattern for library writers in
> the Guice book that was recently published. The guice mailing list is also a
> great place to ask.
>
>>
>>
>>
>> So that a deployer can give the classname of the CacheProvider
>> implementation in the properties file and have it load without having
>> to add another module. It works just fine but ......
>>
>> What's the right way to do this in Guice ?
>>
>> Ian
>>
>
