William Burns created ISPN-1837: ----------------------------------- Summary: Add support for configuration file based configuration override Key: ISPN-1837 URL: https://issues.jboss.org/browse/ISPN-1837 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.1.0.FINAL Reporter: William Burns Assignee: Manik Surtani I totally like the new configuration changes. However one thing that was available before was a way to allow for overrides of configuration to occur from multiple configuration files. This was available with the defineConfiguration method on the CacheManager. This is how I was able to do this in the past and it worked great. {code} for (File file : files) { InfinispanConfiguration readConfig = ...; cacheManager.getDefaultConfiguration().applyOverrides(readConfig.parseDefaultConfiguration()); for (Entry<String, Configuration> entry : readConfig.parseNamedConfigurations().entrySet()) { cacheManager.defineConfiguration(entry.getKey(), entry.getValue()); } } {code} This ability was taken away and the replacement is to use the read method on the various ConfigurationBuilders. This works great for programmatic override of various values. However there is no easy way to do overrides based on a configuration file. This is due to the fact that the only way a user can get ConfigurationBuilder objects from a configuration file is with all the default values provided. Thus you are basically replacing a configuration instead of overriding it. I wanted to propose a simple change to the Parser class so it can now also take a ConfigurationBuilderHolder so then a user can retain their own holder and pass it on to subsequent parse calls. This way only the values read from the parser will be set on the configuration builder objects. With t his small change I am then able to do the following: {code} Parser parser = new Parser(Thread.currentThread().getContextClassLoader()); for (File file : files) { parser.parse(file.getAbsolutePath(), holder); } {code} Also a side note but the way the transport is handled right now kind of throws a wrench in this. I noticed that if the global section is provied if no transport is in the xml it will null out the transport in the configuration on the override. This can be problematic if the transport is defined in a starting xml file and later a different xml file may want to say add some additional externalizers or something (which we do) and then the transport will be set to null. Right now I am working around this by overriding the transport last, but would be nice if I didn't have to do that. I could also define an empty transport element in all of the xml files to workaround it as well. The transport issue occurs because of line 1209 in the Parser class. I don't know if it can be changed without breaking something else and as such didn't include it in my pull request, but would be nice if this could also be changed. {code} if (!transportParsed) { // make sure there is no "default" transport builder.transport().transport(null); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira