[
https://issues.apache.org/jira/browse/DERBY-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571991#action_12571991
]
Dibyendu Majumdar commented on DERBY-3424:
------------------------------------------
Actually, grouping by layer probably won't work anyway, as we would need more
granularity to enable bundles to be loaded by execution environment.
> 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
> Components: JMX
> 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.
