[GEODE-5971] Refactor offline disk store commands to extend SingleGfshCommand base type#2794
Conversation
…hCommand base type Signed-off-by: Peter Tran <ptran@pivotal.io>
|
|
||
| @Category({PersistenceTest.class}) | ||
| public class DescribeDiskStoreCommandIntegrationTest { | ||
| public class DescribeDiskStoreCommandDUnitTest { |
There was a problem hiding this comment.
The test is really an integration test. Tests that use ServerStarterRule (or LocatorStarterRule) don't fork separate JVMs but start a cache within the test JVM itself - this is essentially the definition of an integration test as it applies to the codebase. ClusterStarterRule, on the other hand, does fork separate JVMs and thus all tests that use that rule should be classified as DUnit tests.
…oreIntegrationTest
| import org.apache.geode.management.internal.cli.result.model.ResultModel; | ||
|
|
||
| public class AlterOfflineDiskStoreCommand extends InternalGfshCommand { | ||
| public class AlterOfflineDiskStoreCommand extends SingleGfshCommand { |
There was a problem hiding this comment.
Not sure if this would make sense. these are offline commands. SingleGfshCommand is designed for commands that would change cluster configuration. I would like to see all offline commands stay as GfshCommand or InternalGfshCommand..
There was a problem hiding this comment.
After some offline conversation, the ultimate goal would be to move everything to SingleGfshCommand.
3 participants
Signed-off-by: Peter Tran ptran@pivotal.io
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?
Has your PR been rebased against the latest commit within the target branch (typically
develop)?Is your initial contribution a single, squashed commit?
Does
gradlew buildrun cleanly?Have you written or updated unit tests to verify your changes?
If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and
submit an update to your PR as soon as possible. If you need help, please send an
email to dev@geode.apache.org.