[
https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976143#comment-15976143
]
ASF GitHub Bot commented on GEODE-72:
-------------------------------------
Github user davinash commented on the issue:
https://github.com/apache/geode/pull/456
@kirklund , I will create separate PR for each JIRA and then will close
this PR.
> 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, docs
>
> 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
>
> APIs deprecated after GemFire 5.7 and before 8.0
> * 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
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(),
> getDiskTaskWaiting()
> 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.
> Deprecated in 7.0 and not previously in this list:
> * UniversalMembershipListenerAdapter
> 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()
> 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.
> Also consider removing com.gemstone.gemfire.cache.partition.PartitionListener
> and com.gemstone.gemfire.cache.partition.PartitionManager.
> They have not been deprecated but were never fully supported. Their javadocs
> say:
> Note : Please contact supp...@gemstone.com before using these APIs
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
