You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@geode.apache.org by GitBox <gi...@apache.org> on 2020/06/18 21:03:29 UTC

[GitHub] [geode] jinmeiliao commented on pull request #5249: GEODE-8272 Refactor Restore Redundancy Command

jinmeiliao commented on pull request #5249:
URL: https://github.com/apache/geode/pull/5249#issuecomment-646304378


   > I have a question about the packages and modules of the classes. e.g. `RestoreRedundancyResultsImpl` is in package `org.apache.geode.management.internal.operation`. And it is in `geode-management` module. Its subclass `SerializableRestoreRedundancyResultsImpl` is in a different package `org.apache.geode.internal.cache.control` and a different module `geode-core`. Why these two classes are in different packages and different modules?
   > Also some classes have been moved to a different package. e.g. `RegionRedundancyStatus` and `RestoreRedundancyResults`. Is there a reason for that?
   
   RestoreRedundancyResults is an interface and is external api, RestoreRedundancyResultsImpl is a direct implementation of it. These two are in the geode-management module because cms needs them to convey result data back to the client. "SerializableRestoreRedundancyResultsImpl", however, is needed to convey function call results from locator to servers, it needs to support rolling upgrade, so it needs to implement "FixedDataSerializableID" interface, that's why we have to have it extends RestoreRedundancyResultsImpl and implement the additional interfaces in geode-core.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org