[jira] [Updated] (GEODE-72) Remove deprecated APIs from Geode

["Dan Smith (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Smith updated GEODE-72:
---------------------------
    Fix Version/s:     (was: 2.0.0-incubating)

> 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 support@gemstone.com before using these APIs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)