Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 29686 invoked from network); 19 Feb 2008 17:31:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Feb 2008 17:31:18 -0000 Received: (qmail 94968 invoked by uid 500); 19 Feb 2008 17:31:12 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 94934 invoked by uid 500); 19 Feb 2008 17:31:12 -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 94925 invoked by uid 99); 19 Feb 2008 17:31:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Feb 2008 09:31:12 -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; Tue, 19 Feb 2008 17:30:34 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A474C234C051 for ; Tue, 19 Feb 2008 09:30:43 -0800 (PST) Message-ID: <1035680685.1203442243672.JavaMail.jira@brutus> Date: Tue, 19 Feb 2008 09:30:43 -0800 (PST) From: "Daniel John Debrunner (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3429) Remove system property derby.system.jmx In-Reply-To: <576001277.1203359077775.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-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570324#action_12570324 ] Daniel John Debrunner commented on DERBY-3429: ---------------------------------------------- Another thought is that we need to see MBeans as the mechanism to manage Derby, not just an api into existing management. Thus any application MBeans that are presenting a simplified/application specific view of Derby's management should be using Derby's MBeans to manage Derby. This requires that Derby's MBeans be available. > Remove system property derby.system.jmx > --------------------------------------- > > Key: DERBY-3429 > URL: https://issues.apache.org/jira/browse/DERBY-3429 > Project: Derby > Issue Type: Sub-task > Reporter: Daniel John Debrunner > Priority: Minor > > I don't believe that derby.system.jmx provides any benefit and is counter to the concept of using JMX for management. > The one use case for it from DERBY-1387 is: > Making the Derby JMX automatically available in the MBean server will make it impossible for the user to make some application with an embedded Derby db manageable thorugh JMX without also making Derby manageable thorugh JMX. I would think that this "all or nothing" granularity could be a problem for some applications. So we would need an explicit derby.system.jmx property for enabling the management service anyway. > The functional spec contains no information as to why this is a useful feature. > I wanted to separate out the discussion from the wider issues in DERBY-1387 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.