Community
Participate
Working Groups
When Regions or Subsystems are being used is it possible for multiple ConfigAdmins to be present within the framework. This should be supported and the appropriate data returned from the MBean.
Some design notes. According to the JMX Management Model chapter of the OSGi Enterprise Spec v4.2, there is a single ConfigurationAdminMBean which surfaces config admin to JMX. This is published with object name "osgi.compendium:service=cm,version=1.3" and contains operations on specific PIDs. So we need to decide how to support multiple instances of Config Admin, for example when we run multiple instances of Config Admin in distinct regions in Virgo. The same question also applies to other services such as Permission Admin, the Provisioning Service, and User Admin. ConfigurationAdminMBean Identity -------------------------------- The ConfigurationAdminMBean assumes that a PID uniquely identifies a configuration which is not necessarily the case across multiple instances of Config Admin. Furthermore, only one mbean may be registered to a given mbean server with a specific object name. The following alternatives cope with multiple instances of Config Admin: 1. Use a single ConfigurationAdminMBean intance and change the interface. This is not acceptable for the normal use case of a single instance of Config Admin running alongside a single instance of Gemini Management in an OSGi framework with only one default region. 2. Build the region identifier, or some abstraction of that, into the object name and publish a distinct ConfigurationAdminMBean per instance of Config Admin. We need to determine how to make this consistent with the default behaviour which would not have a region identifier in the object name. This is the preferred alternative. 3. Run a mbean server per Config Admin instance and publish a distinct ConfigurationAdminMBean per instance of Config Admin into distinct mbean servers. This would complicate JMX client access considerably as well as increasing the overhead per region in the JVM. Accessing Multiple Config Admin Instances ----------------------------------------- Given that we need to manage multiple instances of Config Admin from Gemini Management, the basic decision is how many instances of Gemini Management to run. There are two alternatives: A. Single Gemini Management Instance The single instance will be able to load at most one instance of the Config Admin types (otherwise there would be an inconsistent class space which is prevented by the JVM). So it would be necessary to make a cross-class space call to access Config Admin instances in incompatible class spaces. This would naturally be performed using reflection. Either there need to be specific reflective logic for Config Admin, and other such services, or we would need to use some general purpose cross-class space proxying mechanism, which is similar in essence to a remoting mechanism such as distributed OSGi. Specific reflective logic per service does not seem to be a scalable solution as a new set of logic would need to be provided for each service that is to be supported. Using some remoting mechanism such as distributed OSGi seems too high level for what appears to be a basic server management feature. The underlying remoting mechanism would be unmanageable from a JMX perspective unless some means was found for allowing the remoting mechanism to apply to itself, which sounds rather complex and error-prone. B. Instance of Gemini Management per Config Admin instance Running multiple instances of Gemini Management avoids the cross-class space issue, but necessitates some coordination across Gemini Management instances so that their mbeans would not clash (i.e., have the same object name). So it would be necessary to configure each instance of Gemini Management to publish appropriate mbeans. A concern was raised that an instance of Gemini Management would be able to "see" some of the content of other regions. This is a downside, but would also apply in alternative A. Essentially, Gemini Management will need to cope with being able to see bundles and other artefacts which it could not find, e.g., by listing all bundles (which is subject to region filtering). This is the preferred alternative. Solution -------- The solution combines options 2 and B above. Each instance of Gemini Management will be configured into a non-standard mode of publishing its mbeans with the region identifier built into the object names. Gemini Management should provide a configuration mechanism to allow it to be configured with an object name translator. The default behaviour is to publish the standard object names. If an object name translator is present, Gemini Management will use it to translate each object name before registering each mbean and will register the mbean with the translated object name. A region-aware object name translator will simply append the region name to the object name. In the root region of Virgo, we have the option of running without an object name translator for consistency with the standard or with the region-aware object name translator for consistency with the other regions. The latter seems preferable from the perpsective of management clients such as the web admin console as it will provide a more uniform perspective of the various regions in the system. Various mechanisms could be used to configure an object name translator: i. Attach a fragment to Gemini Management and place a Gemini Management defined header in the fragment to name the object name translator class. This has the beauty of being relatively simple, avoiding visible externals in the Gemini Management bundle, and being strictly tied to the lifecycle of Gemini Management. This is the preferred solution. ii. Code an optional package import in Gemini Management and attempt to load the object name translator during activation of Gemini Management and react according to the presence or absence of the object name translator. This is similar to the fragment solution, but exposes a visible external in the optional import. iii. Have Gemini Management look for an object name translator service during activation and react according to the presence or absence of an object name translator service. This would allow multiple object name translators to be provided. It would be complicated by the lifecyce of the object name translator being independent of that of Gemini Management.
I have prepared a contribution to implement this bug at https://github.com/glyn/Gemini-Management The contribution consists of the following commits: 9e98b4069b3b636eeada4b59b7d6582ce4376806 a16cbc964250de290879fedc21d21808c0b57cfb af1013f2c0b467dc17dcd655c7d86cf686c41581 7da7da265e843856331b5a4ab3340cca91f43bf7 The following commit merges the branch containing the contribution (366163-WiringState) into master: dc2cb61a8332d86f6f3cf7bce220f9d986ad9c3a I confirm that I wrote 100% of the code changes, I have the rights to contribute the code, and new Java files have suitable license headers.
Changes submitted to master.
Fixed with patch from Glyn
