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