"bstansberry(a)jboss.com" wrote : As mentioned on the dev list, a lot has been checked in on this. There are some bits of ugliness. Manik, you pointed out the problem with the use of inner classes; I should be able to fix that today. | | Other ugliness: | | 1) MC doesn't like overloading the setter on a property, which is an issue for the properties that are enum types. E.g.: | | | | public CacheMode getCacheMode() | | public void setCacheMode(CacheMode mode) | | public void setCacheMode(String mode) | | | | doesn't work; the MC wants to pass String "REPL_ASYNC" to the overloaded method that takes CacheMode, and thus blows up. | | To fix, I had to do this for CacheMode, IsolationLevel and NodeLockingScheme: | | | | public CacheMode getCacheMode() | | public void setCacheMode(CacheMode mode) | | public void setCacheMode(String mode) // maybe redundant?? | | public String getCacheModeString() | | public void setCacheModeString(String mode) | | | | I don't know if it's practical to add a PropertyEditor to MC to handle enum conversions; for now the above is ugly but works. | It should not require a PropertyEditor as there already is the Enum.valueOf(Class enumType, String name) method. Its just a question of xml configuration parsing layer recognizing the overloaded method and using valueOf on the string accessor. I'll create a jira issue for this. "bstansberry(a)jboss.com" wrote : | 2) Names of properties in Configuration. Configuration can take 2 different types for each of the 3 complex sub-configurations (BR, cache loading, eviction). These are an Element, for legacy support, and a pojo for configuration via the MC. So, 2 properties for each sub-configuration. Problem is naming these properties; the Element properties already have names, but the naming conventions are inconsistent. Changing the Element properties will break existing config files, so I worked around that when naming the pojo properties. Ugly, completely inconsistent result is: | | | | // BR | | public Element getBuddyReplicationConfig() | | public void setBuddyReplicationConfig(Element config) | | | | public BuddyReplicationConfig getBuddyReplicationConfiguration() | | public void setBuddyReplicationConfiguration(BuddyReplicationConfig config) | | | | // Cache Loader | | public Element getCacheLoaderConfiguration() | | public void setCacheLoaderConfiguration(Element config) | | | | public CacheLoaderConfig getCacheLoaderConfig() | | public void setCacheLoaderConfig(CacheLoaderConfig config) | | | | // Eviction | | public Element getEvictionPolicyConfig() | | public void setEvictionPolicyConfig(Element config) | | | | public EvictionConfig getEvictionConfig() | | public void setEvictionConfig(EvictionConfig config) | | | | One temptation is to break compatibility with existing config files for BR by swapping the property names. There aren't likely to be many existing configs that have BR. E.g. | | | | public Element getBuddyReplicationConfiguration() | | public void setBuddyReplicationConfiguration(Element config) | | | | public BuddyReplicationConfig getBuddyReplicationConfig() | | public void setBuddyReplicationConfig(BuddyReplicationConfig config) | | | We should not be exposing any dom objects via the configuration objects. That should only be done via legacy configuration wrapper classes that turn around and write to the pure object based configuration instance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980149#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...