]
Brian Stansberry commented on WFCORE-565:
-----------------------------------------
The "get" methods from DiscoveryOption can legitimately return null before the
"discover()" method is invoked. The uses of
DiscoveryOptionStrategy.DiscoveryOptionComparator are not properly dealing with that.
We need to rethink the DiscoveryOption sorting, as there's sorting going on before
discovery has taken place.
StaticDiscoveryResourceDefinition allows undefined values for its
attributes
----------------------------------------------------------------------------
Key: WFCORE-565
URL:
https://issues.jboss.org/browse/WFCORE-565
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
StaticDiscoveryResourceDefinition reuses the AttributeDefinitions from
RemoteDomainControllerAddHandler, but those ADs allow undefined. That's appropriate
for that OSH, but not for the StaticDiscoveryResourceDefinition ADs.
Also, the RemoteDomainControllerAddHandler AD's could use some clarification and
validation as well, e.g. use setRequires(...) on the builder such that each of protocol,
host, port requires the other two. So none are required, but if any is set all 3 must be.
The StaticDiscovery constructor should validate inputs with assert statements and javadoc
its parameters, include whether null is allowed. (A null protocol or host will result in
an IAE in discover(), so the current code does not support null.)
The DiscoveryOption interface should document whether the 3 "get" methods can
return null.