New Member Filter MBean will be created which allows user to limit which remote members are managed/federated
Managing members will register aggregate MBeans in addition to federated MBeans
These aggregate MBeans provide roll-up views of the entire GemFire system
New remote MBean Filter to specify types of federated MBeans that will be exposed via proxies
Same as the local MBean Filter but a "managing" member should be able to have both Filters configured differently
New Platform Delegate MBeans that extend or wrap selected Platform MXBeans will be added to the Management API
These are copies of Platform MBeans which add Member Id to the object name and can thus be federated to master MBeanServers
Example: MemoryMXBean with ObjectName "java.lang:type=Memory" is mirrored by:
Option 1: MemberMemoryMBean with ObjectName "GemFire:type=Platform,subDomain=java.lang,subType=Memory,id=server1"
Option 2: MemberMemoryMBean with ObjectName "GemFire:type=Member,id=server1,domain=Platform,subDomain=java.lang,subType=Memory"
Customers will be able to create and deploy custom MBeans (implementations of these may access other MBeans as well as GemFire APIs)
Customers desire non-transient MBeans. In order to support this we need a [Persisted Configuration]
Security requirement: MBean invocations must go through GemFire's security layer in the same way that cache client requests do. At a minimum this will likely require creating two new security operations: Management Read, Management Write. Anything reading would require the Management Read permission, while anything that modifies/creates/writes will require the Management Write permission.
Powered by a free Atlassian Confluence Open Source Project License granted to Apache Software Foundation. Evaluate Confluence today.