We need to support XML files as configuration formats. They need to be hierarchical, like the Apache Commons Configuration support, but simpler for the moment. The root element doesn't matter, and the configuration key is considered hierarchical based on the . delimiter. But we don't need to worry about attributes or anything for the moment. Just take the text content of the final node we find.
Because XML just has strings, we can extend from AbstractStringConfiguration and convert all the types from strings. That class should handle almost everything already.
Here is an outline of what needs to be done to complete this task:
Create a confound/config-file-format-xml subproject.
Create an XmlConfiguration class that extends AbstractStringConfiguration. You'll pass it the parsed node tree. Override findParameterImpl(@Nonnull final String key) to return whatever string it looks up in the XML document. Everything else (conversion, etc.) is/should be/will be taken care of.
Create an XmlConfigurationFileFormat class that supports the .xml extension, uses the normal configured Java XML parser to parser the file, and stores the document tree in the XmlConfiguration.
Create a confound/config-file-format-xml-provider subproject. (These will be two separate subprojects as before, so that people can use the file format without necessarily including it as a Csar provider to automatically support that format.)
Add a META-INF//services/io.confound.config.file.ConfigurationFileFormat indicating the XmlConfigurationFileFormat class.
You don't have to worry about any of the parent configuration or fallback stuff. Just implement findParameterImpl() to pass back a string. That's all. The base configuration class takes care of everything else.
You need to pass the XML DOM tree to the implementation when you create it, yes.
If you're lost we can have a meeting tomorrow. But looks at the example implementations first.
Look at the string map implementation. It just looks something up in a map. You'll do the same thing, but instead of looking it up in a map, you'll look it up in the DOM tree. The only difference is that you'll support a hierarchy (by considering the key to be hierarchical).
Get it working with the non-hierarchical version. Pass in foo, and it returns whatever is in <foo>…</foo>. It should be simple and straightforward. Then worry about if the key has . in it, after you get that working.
The method findParameterImpl() returns an Optional<String>, but Document.getElementsByTagName() assumes that there might be multiple elements with the same tag name, are we going to consider it for Confound configuration, or will we consider that we'll have no multiple elements with the same name in the same level for the XML configuration?
And also, we'll treat BOMs in every type of configuration?
Do the simplest implementation, adding comments about what needs to be improved.
Does XML allow a BOM? I don't remember. If it allows it. We should support it.
If I remember correctly, getElementsByTagName searched the whole document. Is that what we want to do? Don't we only accept the key name directly under the root?
You can make a note to use XPath support in the future. Theoretically that could be faster. But for now it's simply to Judyy walk the DOM.