I've developed over the years habits of separating various property changes into different xconf files that are referenced in site.xconf. For example, I have the following:
- configuration.xconf - For any value changes from the defaults, security label configuration, etc.
- customization.xconf - Registered Data Utilities, listeners and other customizations.
- wvs.xconf - Any properties changes that related to WVS service and wvs.properties.
My goal was to keep site.xconf small and very close to static from when it was modified during the upgrade. There are ConfigurationRef lines that bring this custom xconf files into the site.xconf to they propagate properly via xconfmanager.
Recently, I needed a new xconf file (I think) for integrations. This would store username and password values for various custom integrations to other systems and databases. This file would be environment specific (PROD,TEST,DEV) and the passwords needed to be encrypted. I followed the various articles like CS255640 and CS117247 to handle this. Is it me or does this seem clunky? Changes get added to the site.xconf always and it requires moving the entry to the custom xconf on any password change.
Anyone have any better organization methods? There was also a note to add the custom xconf files to declarations.xconf. Not sure what advantage that offers me since I already have them linked in the site.xconf file in the same manner.
