db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3424) Add an MBean that an application can register to change the state of Derby's JMX management
Date Mon, 18 Feb 2008 17:00:35 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569947#action_12569947

Daniel John Debrunner commented on DERBY-3424:

> - To enable Derby-JMX at runtime, the JMX client has to create and register the ManagementMBean
with the MBean server, and then invoke the startManagement() operation. 

or invoke startManagement() on the ManagementMBean if Derby registered it with the platform
mbean server

>  - If the value of derby.system.jmx is true, all the current MBeans are registered with
both the platform MBeanServer 

If Derby can not find the platform MBeanServer then the mbeans will no be registered with
the platform MBeanServer. (e.g. Derby does not have the permission to start the platform server
and it is not running).
Also Derby may not be able to register specific beans (due to permissions) with the platform
mbean server, those will remain registered with Derby's management service but not with jmx.

>     - Then the MBeans "registered" with Derby's management service are also automatically
registered with the MBean server. This currently only includes the VersionMBean.

No for the last sentence,currently the JDBC mbean will also register as well as the VersionMBean,
but this is not hardcoded into Derby's management service, it's just a factor of which mbeans
have been registered with Derby's management service.

A1) No Derby's management service cannot be stopped, I don't see a use case for this.

A2) It's in the working code, JMXManagementService maintains a collection of mbeans that have
been registered with it. When its active state changes it either registers in or unregisters
from the plaform mbean server the mbeans in its collection.

A3) Please feel free to suggest a better term. Note that only in the implementation of Derby's
api is there two uses, the ManagementService api has a single use, just register and unregister,
the implementation can do what it wants with the beans.

A4) I'll clean up the comment.

Thanks for the comments.

> Add an MBean that an application can register to change the state of Derby's JMX management
> -------------------------------------------------------------------------------------------
>                 Key: DERBY-3424
>                 URL: https://issues.apache.org/jira/browse/DERBY-3424
>             Project: Derby
>          Issue Type: New Feature
>            Reporter: Daniel John Debrunner
>            Assignee: Daniel John Debrunner
>            Priority: Minor
> JMX in Derby was originally proposed as a mechanism to configure Derby replacing or enhancing
the system properties which tend to be static in nature. Thus it is somewhat ironic that jmx
is enabled with a static system property derby.system.jmx.
> I propose to add a public mbean that allows the state Derby's JMX management to be changed.
This bean is not automatically registered by Derby if derby.system.jmx is false, but instead
can be registered by an application. I believe this could occur at any time so that JMX could
be enabled on a running application, possibly by a remote client.
> This standard Mbean (o.a.d.mbeans.Management & ManagementMBean) would have these
operations & attribute:
>     public boolean isManagementActive();
>     public void startManagement(); 
>     public void stopManagement();
> If Derby is not booted within the jvm then the operations would be no-ops.
> If derby.system.jmx is true then Derby will itself register an mbean that implements
ManagementMBean to allow dynamic control of the visibility of Derby's mbeans.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message