In order to monitor/control rmid, it's sufficient to have a list of the group IDs
and object IDs which are currently registered. Thereafter, the ActivationSystem
methods can be used to query/manage the list.
However, getting the list is not possible unless each registering application is
willing to serialize and save the ActivationIDs and ActivationGroupIDs it
receives.
A remote API which will list the current idTable.keySet().toArray() value would
allow the caller to get the list of registered ActivationIDs. The method should
probably check for a localhost caller, since the related getActivationDesc (and
friends) also do so, making a nonlocal rmid monitor useless anyway.
There's no need for a getGroupIDList() method, because the information is
available by inspecting the getActivationDesc().getGroupID() value for each ID.
and object IDs which are currently registered. Thereafter, the ActivationSystem
methods can be used to query/manage the list.
However, getting the list is not possible unless each registering application is
willing to serialize and save the ActivationIDs and ActivationGroupIDs it
receives.
A remote API which will list the current idTable.keySet().toArray() value would
allow the caller to get the list of registered ActivationIDs. The method should
probably check for a localhost caller, since the related getActivationDesc (and
friends) also do so, making a nonlocal rmid monitor useless anyway.
There's no need for a getGroupIDList() method, because the information is
available by inspecting the getActivationDesc().getGroupID() value for each ID.
- duplicates
-
JDK-4489638 Facility for RMID to list contents of its log
-
- Closed
-