[ https://issues.apache.org/jira/browse/GEODE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Barnes updated GEODE-72: ----------------------------- Labels: cleanup docs (was: cleanup) > 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.4#6332)