Thomas Eichstädt-Engelen wrote:
Hi Oliver,
thanks for your quick response.
Or could you provide a more detailed example with such an overridden
bean declaration that causes ambigous keys?
Let's assume i have two XmlConfigurations. Both of which are configured in my
configuration-definition.xml file. The order is SpecialisedConfiguration at
first followed by GeneralConfiguration.
SpecialisedConfig (lies somewhere editable for my operationsTeam)
<jobs>
<job_1 secretKey="geheim" />
</jobs>
and the GeneralConfig (is packed into a war-file)
<jobs>
<job_1 config-class="de.eichstaedt.ClassToCreateViaBeanUtils"
secretKey="anfang"
attribut_1="foo"
attribut_2="bar" />
<job_2 [...] />
[...]
</jobs>
Now I use a DefaultConfigurationBuilder to create my configuration object as
described in the UserGuide:
DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
builder.setFile(new File("configuration.xml"));
CombinedConfiguration cc = builder.getConfiguration(true);
After that i start the bean creation with:
// get a combined subConfig with
// overridenValues to build a Bean from
HierchicalConfiguration config = cc.configurationAt("jobs.job_1")
BeanDeclaration decl = new XMLBeanDeclaration(config);
ClassToCreateViaBeanUtils createdClass = (ClassToCreateViaBeanUtils)
BeanHelper.createBean(decl);
At this point i assumed to get a view to one combined configuration and to get
a Configuration with the overriden secretKey attribute. But an exception is
thrown instead.
My workaround is to create a combined node via getRootNode(). It worked but in
this case all that previoulsy configured stuff e.g. ReloadingStratety,
NodeCombiner, etc. disappears because i created a new XmlConfiguration from
that RootNode.
I think the exception at configruationAt() - implemented in
HierarchicalConfiguration - occured because it simply fetches a nodeList with
the given key. It does not take into account that one configuration has
overriden some values of the other one. That is clear because the overriding
behaviour is added deeper in the ClassHierarchy initially with the
CombinedConfiguration. Thus i assumed to find a specialised version of
configurationAt() dealing with the combinedRoot in that class.
Does my question became clearer now? Sorry for my english ...
Kind regards from Germany,
Thomas E.-E.
Thomas,
yes, I think I understand your problem now. I tried to reproduce it, but
without success. I have written the following test case:
public void testCombinedAttributes()
{
HierarchicalConfiguration c1 = new HierarchicalConfiguration();
c1.addProperty("[EMAIL PROTECTED]", "geheim");
HierarchicalConfiguration c2 = new HierarchicalConfiguration();
c2.addProperty("[EMAIL PROTECTED]",
Object.class.getName());
c2.addProperty("[EMAIL PROTECTED]", "test");
c2.addProperty("[EMAIL PROTECTED]", "foo");
c2.addProperty("[EMAIL PROTECTED]", "test2");
CombinedConfiguration cc = new CombinedConfiguration(new
OverrideCombiner());
cc.addConfiguration(c1);
cc.addConfiguration(c2);
assertEquals("geheim", cc.getProperty("[EMAIL PROTECTED]"));
HierarchicalConfiguration c3 = cc.configurationAt("jobs.job_1");
assertEquals("geheim", c3.getString("[EMAIL PROTECTED]"));
}
Here I create a combined configuration manually by combining two
hierarchical configurations with similar content as in your example.
This seems to work. I can call configurationAt(), and the resulting sub
configuration has the overridden attribute.
Note that CombinedConfiguration does not need its own implementation of
configurationAt(). Its content is produced by a NodeCombiner object,
which already takes overriding properties into account.
So, I am not sure why you get an exception. What you can do for testing
purposes is to dump your combined configuration to see how it looks like:
XMLConfiguration xmlconf = new XMLConfiguration(cc);
xmlconf.save("combined.xml");
(The constructor that takes another configuration was added after the
1.3 release, so you need a recent nightly build to check this.) This
should create a XML file with the content of the combined configuration.
Maybe this is helpful to find out why the key is ambiguous.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
