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-3429) Remove system property derby.system.jmx
Date Thu, 21 Feb 2008 18:23:20 GMT

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

Daniel John Debrunner commented on DERBY-3429:
----------------------------------------------

Thanks for the comments John.

This concept of disabling user management of Derby and only allowing application level management
is hard for me to grasp, especially without a security manager. Assuming applications will
typically present a nice-console (using jmx beans under the covers) then they can easily hide
any MBeans they don't won't to expose.

Thus the concern would be two classes of users:

   - those smart enough to use a generic jmx console
   - those even smarter who can write jmx code.

With Derby's MBeans a jmx client in a system without a security manager can monitor and control
the jvm itself, create any MBeans that are available on the server's classpath to control
any other software, thus it's not really just a Derby issue.

My concern is that we might be solving this mythical use case at the expense of the more typical
known use case, which is:
  - I have an intermittent  problem in my running application, how can I see what is going
on?
Having to reboot to start JMX and then wait for the problem again does not seem acceptable.

I agree that potentially reversing the state of the property, or to be clearer having an explicit
property "derby.jmx.disable=true" could be an option, but only once there's some proven need
for it. The functionality can be implemented today using the security manager, having a property
that encourages use without a security manager to allow potentially insecure remote monitoring
does not seem a good direction.

I'll wait a few days and then proceed to remove derby.system.jmx.



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


Mime
View raw message