Use non-bundled JGroups discovery protocol

[ceharris]

I'm deploying an application using Wildfly 10 on AWS. I want to use the JGroups TCP stack with the AWS_PING protocol for JGroups discovery.

I packaged up the AWS_PING protocol and the required AWS SDK dependencies as Wildfly modules; see https://github.com/soulwing/wildfly-jgroups-aws-ping/releases/tag/1.0.0

I used the 'awsping' module slot to avoid a potential future conflict for the module names I created.

I modified the existing jgroups module.xml (modules/systems/layers/base/org/jgroups/main/module.xml) so that it includes a dependency on my org.jgroups.aws module as shown in the attached 'jgroups-module.xml'.

I changed the 'ee' channel in the standalone-ha.xml configuration to use the 'tcp' protocol, and replaced the MPING protocol in that stack with AWS_PING using the CLI commands in the attached 'aws-ping-cli.txt'.

When I start up Wildfly using this configuration, it stops with an error:

13:37:56,170 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 24) WFLYCTL0013: Operation ("add") failed - address: ([

    ("subsystem" => "jgroups"),

    ("channel" => "ee")

]) - failure description: "WFLYCLJG0016: Unable to load protocol class com.meltmedia.jgroups.aws.AWS_PING"

Not sure how to debug it from here. Obviously, I'm missing something, but I'm not sure where to look next.

I also tried building my modules to use the 'main' slot, and adjusted all of the configuration accordingly, but that didn't change the outcome.

[ceharris]

The issue turned out to be that my AWS ping module specified an invalid dependency; "org.slf4j.api" should have been "org.slf4j".

In order to determine the cause of the problem, I compiled Wildfly from source after adding a line to the throws clause of the findProtocolClass method of https://github.com/wildfly/wildfly/blob/master/clustering/jgroups/extension/src/main/java/org/jboss/as/clustering/jgroups/subsystem/ProtocolResourceRegistrationHandler.java to output the actual error that occurred in loading the class.

It might be helpful to treat ModuleLoadException differently than ClassNotFoundException, and in the case of the former, log the error message of the exception.