You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2008/02/18 19:24:37 UTC
[jira] Created: (DERBY-3429) Remove system property
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.
[jira] Commented: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637103#action_12637103 ]
Kristian Waagan commented on DERBY-3429:
----------------------------------------
I notice there are still references to "derby.system.jmx" in Derby source code comments.
> Remove system property derby.system.jmx
> ---------------------------------------
>
> Key: DERBY-3429
> URL: https://issues.apache.org/jira/browse/DERBY-3429
> Project: Derby
> Issue Type: Sub-task
> Components: JMX
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
> Priority: Minor
> Fix For: 10.4.1.3
>
>
> 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.
[jira] Commented: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569982#action_12569982 ]
Daniel John Debrunner commented on DERBY-3429:
----------------------------------------------
If an application is using a security manager then it provides a much more flexible mechanism to control which of Derby's MBeans are visible than the all or nothing approach of derby.system.jmx.
An application using an embedded Derby with its own policy file can:
- disable Derby from registering any MBeans
- allow Derby to only register specific MBeans
- allow authenticated JMX users to only perform specific actions on Derby's MBeans.
Having Derby always attempt to register its MBeans (as if derby.system.jmx=true) i think provides a much more flexible environment, an application can provide limited or no management of Derby directly but also support a "drill-down" for more sophisticated users.
The functionality being added in DERBY-3424 also allows the application to control the visibility of Derby's MBeans in a dynamic manner rather than the static manner of 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.
[jira] Assigned: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner reassigned DERBY-3429:
--------------------------------------------
Assignee: Daniel John Debrunner
> Remove system property derby.system.jmx
> ---------------------------------------
>
> Key: DERBY-3429
> URL: https://issues.apache.org/jira/browse/DERBY-3429
> Project: Derby
> Issue Type: Sub-task
> Components: JMX
> Reporter: Daniel John Debrunner
> Assignee: 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.
[jira] Commented: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "John H. Embretsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570998#action_12570998 ]
John H. Embretsen commented on DERBY-3429:
------------------------------------------
If we remove this system property and enable Derby JMX management by default, then the only recommended way for a user (admin) to allow JMX management of his application embedding Derby, but not Derby itself, is to use a security manager, correct?
This means that if the user (admin) is not willing to use a security manager to limit JMX exposure, he must accept that valid JMX users may see and access Derby's MBeans. I don't see how this is much different from today, when a valid JMX user (client) may enable Derby's ManagementMBean programmatically even if the system property has not been set. This will in turn enable all relevant Derby MBeans.
So, I think this is an acceptable approach.
An alternative approach is to reverse the default value of the property, so that a user has to set it (to false) if he does not want to enable Derby's MBeans by default.
Then, for example, JConsole users won't see MBeans related to Derby by default. It would still be possible to enable Derby's MBeans at runtime, using the ManagementMBean, so the usefulness of such a knob may be limited (it won't stop dedicated (and valid) JMX users from enabling the MBeans).
At the moment I don't know of any other use cases supporting the need to enable Derby-JMX with a static knob.
> 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.
[jira] Closed: (DERBY-3429) Remove system property derby.system.jmx
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner closed DERBY-3429.
----------------------------------------
Resolution: Fixed
Fix Version/s: 10.4.0.0
Property removed with Revision: 631335
> Remove system property derby.system.jmx
> ---------------------------------------
>
> Key: DERBY-3429
> URL: https://issues.apache.org/jira/browse/DERBY-3429
> Project: Derby
> Issue Type: Sub-task
> Components: JMX
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
> Priority: Minor
> Fix For: 10.4.0.0
>
>
> 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.
[jira] Commented: (DERBY-3429) Remove system property
derby.system.jmx
Posted by "Daniel John Debrunner (JIRA)" <ji...@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.