1 2 Previous Next 18 Replies Latest reply: Feb 24, 2011 1:41 PM by Galder Zamarreño Go to original post RSS
  • 15. Re: Configuration API changes in 5.0
    Galder Zamarreño Master

    I can understand your worries of clustering classes like TransportConfig with clustering(),expiration()...etc. However, there's a clear workaround for this. What about something like this?

     

    gc.transport().clusterName("blah").machineId("id").rackId("rack").strictPeerToPeer(true)
        .gc().asyncTransportExecutor().factory(DefaultExecutorFactory.class).addProperty("blah", "blah")
        .gc().globalJmxStatistics().enabled(true).jmxDomain("org.galder");
    

     

    Basically, gc() would be a handle in each *Config to get hold of the global configuration. I don't care about the name of the method as long as it's not too long.

     

    A similar thing would be required for Cache level configuration.

  • 16. Re: Configuration API changes in 5.0
    Galder Zamarreño Master

    Btw, can you simplify cache loader configuration further? At the moment you do:

     

    LoadersConfig loaders = c.configureLoaders();
    loaders.passivation(true).preload(true).shared(false);
    FileCacheStoreConfig fcsc = new FileCacheStoreConfig();
    fcsc.configureAsyncStore().enabled(true).flushLockTimeout(1000L);
    fcsc.configureSingletonStore().pushStateTimeout(1000L).enabled(true);
    loaders.addCacheLoaderConfig(fcsc);
    

     

    What about:

     

    c.loaders().passivation(true).preload(true).shared(false)
      .add(new FileCacheStoreConfig())
         .asyncStore().enabled(true).flushLockTimeout(1000L)
         .singletonStore().pushStateTimeout(1000L).enabled(true);
    

     

     

    The key thing would be that add() could return a type T based on the parameter it receives. A very similar thing like what's done with AbstractComponentRegistry where getComponent returns an instance of type T based on the class type passed. Here it'd be simpler:

     

    LoadersConfig.add would something like:

     

    public <T> T add(Object<T extends CacheLoaderConfig> loader)

     

    Thoughts?

  • 17. Re: Configuration API changes in 5.0
    Vladimir Blagojevic Master

    Yeah, I think noone would object to this change with T type parametrization. Good catch!

     

    However, I am not sure about changing configureXYZ to XYZ because I want to keep clear separation between properties of a current configuration object and configuration descendant objects. If we remove configure### that would cause some confiusion, don't you think so?

  • 18. Re: Configuration API changes in 5.0
    Galder Zamarreño Master

    Actually, my suggestions needs further baking. Think about chaining cacheloaders. It'd be nice to do:

     

    c.loaders().passivation(true).preload(true).shared(false)
       .add(new FileCacheStoreConfig())
          .asyncStore().enabled(true).flushLockTimeout(1000L)
          .singletonStore().pushStateTimeout(1000L).enabled(true)
       .add(new JDBCCacheLoader)
          .asyncStore(false).enabled(false)....
    

     

    So, T, would need to extend LoadersConfig to be able to do that. Have a think about it. The point is, I think there're opportunities to make the config a lot more fluent.

     

    Btw, you should involve Emmanuel Bernard who, I believe, is quite an expect on these type of fluent APIs. Also, the dev list might not be aware we're discussing this here in the user forum, so I'd suggest you let them now or move the discussion to the dev list. I like the fact that we can show code in a nice way through here though.

1 2 Previous Next