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

John H. Embretsen commented on DERBY-3424:
------------------------------------------

The commit of rev 628943 fixed the issue with class loading. I'm glad it was as 
simple as that! I successfully tried enabling, disabling, re-enabling etc. of 
Derby's JMX management, and it seemed to work well.

Regarding the object name of the Management MBean, it is in any case up to the 
client application to define which domain it wants to use. I think, however, 
that if we are to document an example of doing this, we could just as well use 
"org.apache.derby" as the domain (and "type=Management" as its only key 
property). Otherwise the user will see two MBeans representing the management 
bean, providing the same functionality (at least until DERBY-3429 is 
implemented).

The javadoc for javax.management.ObjectName says:

"a useful convention is to begin the domain name with the reverse DNS name of 
the organization that specifies the MBeans, followed by a period and a string 
whose interpretation is determined by that organization."

I was thinking that "specifies the MBeans" means providing the code defining 
the MBean (interface/class), but I could be wrong. No big deal, though.

> 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.

Reply via email to