Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 82270 invoked from network); 17 Feb 2008 16:21:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Feb 2008 16:21:03 -0000 Received: (qmail 88099 invoked by uid 500); 17 Feb 2008 16:20:58 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 88070 invoked by uid 500); 17 Feb 2008 16:20:58 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 88061 invoked by uid 99); 17 Feb 2008 16:20:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Feb 2008 08:20:57 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Feb 2008 16:20:20 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 917C9234C03F for ; Sun, 17 Feb 2008 08:20:34 -0800 (PST) Message-ID: <2032363093.1203265234594.JavaMail.jira@brutus> Date: Sun, 17 Feb 2008 08:20:34 -0800 (PST) From: "John H. Embretsen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3424) Add an MBean that an application can register to change the state of Derby's JMX management In-Reply-To: <23873038.1203094568401.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569713#action_12569713 ] John H. Embretsen commented on DERBY-3424: ------------------------------------------ Interesting approach. So I guess the plan is to allow remote JMX clients to enable Derby-JMX at runtime by doing something like this? JMXServiceURL url = new JMXServiceURL( "service:jmx:rmi:///jndi/rmi://" + HOSTNAME + ":" + JMXPORT +"/jmxrmi"); JMXConnector jmxc = JMXConnectorFactory.connect(url, null); MBeanServerConnection mbeanServerConn = jmxc.getMBeanServerConnection(); ObjectName mgmtObjName = new ObjectName("org.apache.derby", "type", "Management"); ObjectInstance mgmtObj = mbeanServerConn.createMBean("org.apache.derby.mbeans.Management", mgmtObjName); (and then invoke operations on that MBean). With the current code line, I get an Exception in thread "main" javax.management.ReflectionException: The MBean class could not be loaded by the default loader repository I assume some special handling of class loaders/loading is needed on the server-side as long as we're using the platform MBeanServer... any thoughts on this? An admin can probably control access to this feature by using a security policy file, but are there any specific plans within the 10.4 timeframe with regards to security & this feature? > 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.