1. What happened with annotations?
2. We should make it really, really easy (for me ;) or anyone else) to dump additional objects in ejbca without having to understand how the Configdump project works. Preferably, the workflow could be something like:
a. Add a new class in the objects namespace implementing the 'ConfigdumpExportable' interface.
b. Implement the correspoding unit test for this class
c. Add the new ConfigdumpExportable to a list of exportables in ConfigdumpSessionBean.
3. How are upgrades in the output format handled? For example, if the format is different between EJBCA 6.12 and EJBCA 6.13 how do we upgrade from the old format to the new format? I don't think this would happen
very often since even if we refactor the underlying objects in EJBCA, this won't necessarily affect the output format (which is not the case with old statedump). The only way to handle this (as far as I can tell) without writing
an upgrade routine is to upgrade EJBCA itself
a Import a dump with the old YAML format into an old EJBCA instance supporting this format
b Upgrade to new EJBCA
c Export the configuration using the new YAML format
From what I understand, this is not what we want i.e. we need to be able to upgrade an old YAML file to a new one. To do this we would need the following:
a Metadata which tells Configdump how to handle the two possible cases outlined below
- A field exists in dump but not in EJBCA
- A field exists in EJBCA but not in the dump
Additionally we should consider the case where
- A field exists twice (violates the YAML spec)
- A field has an invalid value
- Fields have an invalid combination of values
- A YAML object (for example an internal key binding) refers to another YAML object (for example a crypto token) which does not exist
b A version field telling Configdump which version of the format we're dealing with. This should preferably be defined on file level, to allow a user to mix configuration files from different installations.
This would only be problem during import, not during export. But if we don't take these things into consideration now, we may have to waste time refactoring later.
4. How should one YAML object refer to another YAML objects?
a By name - they are not guaranteed to be unique in an EJBCA installation
b By ID (which is not human readable and can cause confusion if a user changes them). Also adds additional implementation complexity if they already exists during import and need to be changed
c Using YAML anchors, this introduces dependencies e.g. if an internal key binding is exported you also need to export the corresponding crypto token since you'll need to refer to something which exists. Not sure if
anchors work if you export into several different files. In that case you would have to merge all files before an import
Add some missing javadoc before shipping (i.e. can be done later).
I would prefer to take some classes apart even more, Configdump core could be split into YamlExporter, ConfigdumpConfiguration and ConfigdumpCore where
YamlExporter is responsible for exporting to YAML (invoking SnakeYAML, creating directory tree and writing files to the correct directories), ConfigdumpConfiguration contains the configuration (e.g. loaded from a YAML file) and
ConfigdumpCore contains some functions for mapping between names and ids ect.