done
[ Full content available at: https://github.com/apache/geode/pull/4692 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
We added "getFuture" to the ClusterManagementService. We thought this was
cleaner than adding "getFuture" to ClusterManagementOperationResult because if
we did that it would need to have a reference to the ClusterManagementService
to repeatedly call "get".
[ Full content available at:
I filed a geode ticket about moving those methods up to OperationResult.
The team talked and we decided it would be best to keep the impl class
[ Full content available at: https://github.com/apache/geode/pull/4692 ]
This message was relayed via gitbox.apache.org for
I filed: https://issues.apache.org/jira/browse/GEODE-7803 for this
[ Full content available at: https://github.com/apache/geode/pull/4692 ]
This message was relayed via gitbox.apache.org for
notifications@geode.apache.org
ps: I'm fine with some other name for the class that implements the
RebalanceResult.
I also find it odd that RebalanceResult has "getSuccess()" and
"getStatusMessage()" but its super interface "OperationResult" is empty. It
seems like both of these would be reasonable things to expect from
This PR did not introduce RebalanceResult nor RebalanceResultImpl.
I prefer keeping the current interface and having an internal implementation
class. This prevents our external apis from having internal things exposed. For
example, in this case, the external api does not need a constructor nor
