[
https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-72:
----------------------------------
Description:
The Geode APIs are riddled with old, deprecated interfaces, methods and
settings inherited from GemFire. Unless there is a good reason to keep them
shouldn't we remove them all before going out of incubation?
Sub-tasks have been added for most items. Here are the remaining items not yet
added:
APIs deprecated in GemFire 5.1:
* DLS.lockInterruptibly(), suspendLockingInterruptibly()
APIs deprecated in an undocumented version prior to 5.7:
* Use of hostname:port to specify a locator in gemfire.properties
* AdminDistributedSystemFactory.bindToAddress()
APIs deprecated in GemFire 5.7:
* AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers()
APIs deprecated after GemFire 5.7 and before 8.0
* The com.gemstone.gemfire.admin and admin.jmx packages. Some of the
implementation is in com.gemstone.gemfire.internal.remote.
* EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never
deprecated EvictionAttributes.createLIFOEntryAttributes
nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used
internally by the product when a server create a queue to send subscription
events to a client (see BridgeServerImpl.clientMessagesRegion). I think the
algorithms were deprecated because we didn't intend to expose this internal
feature as an external one. But they are exposed externally via
EvictionAttributes so it is not clear that we can just delete them.
The other consideration is that we do not have xsd support nor gfsh support for
LIFO.
* Region.getCache(): we should consider un-deprecating this. Customers were
supposed to instead call Region.getRegionService but in lots of cases they
would need to down cast that result to "Cache". Only clients that are calling
ClientCache.createAuthenticatedView end up with Regions whose getCache throws
UnsupportedOperationException. Our code call getCache from over 500 places.
* Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
* Locator.getLocators(), hasLocators()
APIs deprecated since GemFire 5.7 with no version information mentioned
* UniversalMembershipListenerAdapter
* DistributedRegionMXBean.getDiskTaskWaiting()
* MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
* RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(),
getDiskTaskWaiting()
LocatorLauncher.DEFAULT_LOCATOR_PORT, DEFAULT_ENABLE_PEER_LOCATION,
DEFAULT_ENABLE_SERVER_LOCATION,
DEFAULT_LOCATOR_PID_FILE
* LocatorLauncher.stopWithPort()
* ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE
Things that should be deprecated but are not:
* MembershipAttributes and “required roles”.
* DynamicRegions: if GEODE-215 is implemented then we could deprecate
DynamicRegions and have an alternative to change to. We have some support in
the gfsh/management layer for creating regions remotely which might be good
enough to deprecate DynamicRegions. The question is should we remove
com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been
deprecated.
APIs deprecated in 8.0. It would probably be a nice gesture to Pivotal to keep
these for a while to allow people to migrate from their GemFire product to
Geode.
* PutAllOperationContext.setMap()
* FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
* ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication,
jmx-manager-ssl distribution properties
* RegionMXBean.getAvgBucketSize()
* com.gemstone.gemfire.LicenseException
The Admin API and packages are also marked as deprecated but there seem to be
some gfsh dependencies on this API, so I'm not sure if it can be removed.
was:
The Geode APIs are riddled with old, deprecated interfaces, methods and
settings inherited from GemFire. Unless there is a good reason to keep them
shouldn't we remove them all before going out of incubation?
Sub-tasks have been added for most items. Here are the remaining items not yet
added:
APIs deprecated in GemFire 5.1:
* DLS.lockInterruptibly(), suspendLockingInterruptibly()
APIs deprecated in an undocumented version prior to 5.7:
* Use of hostname:port to specify a locator in gemfire.properties
* AdminDistributedSystemFactory.bindToAddress()
APIs deprecated in GemFire 5.7:
* AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers()
APIs deprecated after GemFire 5.7 and before 8.0
* The com.gemstone.gemfire.admin and admin.jmx packages. Some of the
implementation is in com.gemstone.gemfire.internal.remote.
* EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we never
deprecated EvictionAttributes.createLIFOEntryAttributes
nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used
internally by the product when a server create a queue to send subscription
events to a client (see BridgeServerImpl.clientMessagesRegion). I think the
algorithms were deprecated because we didn't intend to expose this internal
feature as an external one. But they are exposed externally via
EvictionAttributes so it is not clear that we can just delete them.
The other consideration is that we do not have xsd support nor gfsh support for
LIFO.
* Region.getCache(): we should consider un-deprecating this. Customers were
supposed to instead call Region.getRegionService but in lots of cases they
would need to down cast that result to "Cache". Only clients that are calling
ClientCache.createAuthenticatedView end up with Regions whose getCache throws
UnsupportedOperationException. Our code call getCache from over 500 places.
* DistributedSystem.connect(), disconnect()
* Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
* Locator.getLocators(), hasLocators()
APIs deprecated since GemFire 5.7 with no version information mentioned
* UniversalMembershipListenerAdapter
* DistributedRegionMXBean.getDiskTaskWaiting()
* MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
* RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(),
getDiskTaskWaiting()
LocatorLauncher.DEFAULT_LOCATOR_PORT, DEFAULT_ENABLE_PEER_LOCATION,
DEFAULT_ENABLE_SERVER_LOCATION,
DEFAULT_LOCATOR_PID_FILE
* LocatorLauncher.stopWithPort()
* ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE
Things that should be deprecated but are not:
* MembershipAttributes and “required roles”.
* DynamicRegions: if GEODE-215 is implemented then we could deprecate
DynamicRegions and have an alternative to change to. We have some support in
the gfsh/management layer for creating regions remotely which might be good
enough to deprecate DynamicRegions. The question is should we remove
com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been
deprecated.
APIs deprecated in 8.0. It would probably be a nice gesture to Pivotal to keep
these for a while to allow people to migrate from their GemFire product to
Geode.
* PutAllOperationContext.setMap()
* FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
* ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication,
jmx-manager-ssl distribution properties
* RegionMXBean.getAvgBucketSize()
* com.gemstone.gemfire.LicenseException
The Admin API and packages are also marked as deprecated but there seem to be
some gfsh dependencies on this API, so I'm not sure if it can be removed.
> Remove deprecated APIs from Geode
> ---------------------------------
>
> Key: GEODE-72
> URL: https://issues.apache.org/jira/browse/GEODE-72
> Project: Geode
> Issue Type: Improvement
> Affects Versions: 1.0.0-incubating
> Reporter: Bruce Schuchardt
> Labels: cleanup
>
> The Geode APIs are riddled with old, deprecated interfaces, methods and
> settings inherited from GemFire. Unless there is a good reason to keep them
> shouldn't we remove them all before going out of incubation?
> Sub-tasks have been added for most items. Here are the remaining items not
> yet added:
> APIs deprecated in GemFire 5.1:
> * DLS.lockInterruptibly(), suspendLockingInterruptibly()
>
> APIs deprecated in an undocumented version prior to 5.7:
> * Use of hostname:port to specify a locator in gemfire.properties
> * AdminDistributedSystemFactory.bindToAddress()
>
> APIs deprecated in GemFire 5.7:
> * AdminDistributedSystemJmxImpl.manageCacheServer(), manageCacheServers()
>
> APIs deprecated after GemFire 5.7 and before 8.0
> * The com.gemstone.gemfire.admin and admin.jmx packages. Some of the
> implementation is in com.gemstone.gemfire.internal.remote.
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we
> never deprecated EvictionAttributes.createLIFOEntryAttributes
> nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used
> internally by the product when a server create a queue to send subscription
> events to a client (see BridgeServerImpl.clientMessagesRegion). I think the
> algorithms were deprecated because we didn't intend to expose this internal
> feature as an external one. But they are exposed externally via
> EvictionAttributes so it is not clear that we can just delete them.
> The other consideration is that we do not have xsd support nor gfsh support
> for LIFO.
> * Region.getCache(): we should consider un-deprecating this. Customers were
> supposed to instead call Region.getRegionService but in lots of cases they
> would need to down cast that result to "Cache". Only clients that are calling
> ClientCache.createAuthenticatedView end up with Regions whose getCache throws
> UnsupportedOperationException. Our code call getCache from over 500 places.
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * UniversalMembershipListenerAdapter
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(),
> getDiskTaskWaiting()
> LocatorLauncher.DEFAULT_LOCATOR_PORT, DEFAULT_ENABLE_PEER_LOCATION,
> DEFAULT_ENABLE_SERVER_LOCATION,
> DEFAULT_LOCATOR_PID_FILE
> * LocatorLauncher.stopWithPort()
> * ServerLauncher.DEFAULT_SERVER_PORT, DEFAULT_SERVER_PID_FILE
> Things that should be deprecated but are not:
> * MembershipAttributes and “required roles”.
> * DynamicRegions: if GEODE-215 is implemented then we could deprecate
> DynamicRegions and have an alternative to change to. We have some support in
> the gfsh/management layer for creating regions remotely which might be good
> enough to deprecate DynamicRegions. The question is should we remove
> com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been
> deprecated.
> APIs deprecated in 8.0. It would probably be a nice gesture to Pivotal to
> keep these for a while to allow people to migrate from their GemFire product
> to Geode.
> * PutAllOperationContext.setMap()
> * FixedPartitionResolver.getPartitionName(EntryOperation, Set<String>)
> * ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication,
> jmx-manager-ssl distribution properties
> * RegionMXBean.getAvgBucketSize()
> * com.gemstone.gemfire.LicenseException
> The Admin API and packages are also marked as deprecated but there seem to be
> some gfsh dependencies on this API, so I'm not sure if it can be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
