[
https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715573#comment-14715573
]
Kirk Lund commented on GEODE-72:
--------------------------------
The MXBeans listed as being deprecated since 5.7 were not introduced until 7.0.
I'll investigate further and correct the description for them.
> 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
>
> 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.
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
