1 2 Previous Next 18 Replies Latest reply on Feb 24, 2011 1:41 PM by galder.zamarreno Go to original post
      • 15. Re: Configuration API changes in 5.0
        galder.zamarreno

        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.zamarreno

          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
            vblagojevic

            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.zamarreno

              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