We need a simple domain mode smoke test that will fail if a new extension is added without corresponding adjustments to the domain.xml host-exclude resources.

I had a complicated slow approach in mind that I wrote here before; it's stricken out below.

Much simpler approach:

Add a test to testsuite domain that uses a DC running the standard domain.xml. Read from the DC all the extensions. Work through the host-exclude resources. For each host-exclude, take a copy of the set of extensions, remove those listed in the host-exclude and compare the result to a known correct set of extensions for that version.

If we add a new extension and don't host-exclude it, this will fail. This really is all that's needed to avoid completely skipping the host-excludes.

If we add a new host-exclude and don't add the correct set of extensions to the test, the test will fail. This will help ensure the test isn't completely unmaintained.

It doesn't cover people forgetting to add a new legacy version host-exclude when adding the first extension in a new version, but that can be tracked via code review or just being reasonably careful.

Original complicated approach:

-We need a simple test that a slave running the version before the current one can boot and run a minimal server. Basically to catch the need for a fix like WFLY-10396 whenever we add a new extension.

Something like:

Base domain config must be the standard one we ship. It will include all extensions.

Test adds a minimal profile – bare bones logging subsystem or perhaps no subsystem at all, can only have config that has been legal from the beginning – and a server group using that profile. The server-group is added to the 'active-server-groups' attribute in the host-exclude resource for the slave's version.

Slave host.xml has 1 server only, and in that server group.

Launch the DC using the current release and the slave using the legacy release. Prove the slave server can start.-