When provisioning the server with the wildfly-maven-plugin using the cloud-default-config layer:

<layers>
    <layer>cloud-default-config</layer>
</layers>

when trying and starting the server locally, an error is thrown that is about some missing protocol in the JGROUPS stack and prevents the server from working correclty:

./target/server/bin/standalone.sh

...
16:35:03,309 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ROOT.war")]) - Stage: (VERIFY) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ROOT.war\".component.testQueueMDB.CREATE" => "Failed to start service
    Caused by: java.lang.IllegalStateException"}}
16:35:03,364 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "jgroups"),
    ("channel" => "ee")
]) - Stage: (VERIFY) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.clustering.jgroups.channel.ee" => "java.lang.IllegalStateException: java.lang.Exception: events [FIND_INITIAL_MBRS FIND_MBRS] are required by GMS, but not provided by any of the protocols below it
    Caused by: java.lang.IllegalStateException: java.lang.Exception: events [FIND_INITIAL_MBRS FIND_MBRS] are required by GMS, but not provided by any of the protocols below it
    Caused by: java.lang.Exception: events [FIND_INITIAL_MBRS FIND_MBRS] are required by GMS, but not provided by any of the protocols below it"}}
...

it can be fixed with e.g. (although it might require some investigation - see https://access.redhat.com/solutions/3078171):

/subsystem=jgroups/stack=tcp/protocol=PING:add(add-index=1)

Although cloud-default-config layer is just intended for the cloud we have the following observations:

• we suppose the average developer would try and run things locally before deploying in the cloud (just like we did); refining the setup usually requires a lot of iterations and trying things locally significantly speed things up
• "standalone.sh" would most probably be used to start the server in such iterations (openshift-launch.sh script should work once all the required environment variables are set but we suppose that the average developer isn't aware of its existence)
• the cloud-server layer runs locally right away with "standalone.sh" and no special setup
• we explicitly recommend users to use the "cloud-default-config" layer in e.g. https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_application_platform/8.0/html/using_single_sign-on_with_jboss_eap/securing-applications-deployed-on-server-with-single-sign-on_default

For these reasons, we would like to have servers provisioned with cloud-default-config to run locally with "standalone.sh"; looks like ans easy change (just add PING protocol to jgroups tcp stack);

Alternatively, we might suggest a different set up in our documentation: one that allows a developer to iterate locally before moving to OpenShift;