[infinispan-issues] [JBoss JIRA] (ISPN-1837) Add support for configuration file based configuration override
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