[
https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565761#action_12565761
]
John H. Embretsen commented on DERBY-1387:
------------------------------------------
@Kim: Thanks. As the spec stabilizes, it will probably become more clear what
is needed wrt. documentation.
@Thomas: I agree that it could be clearer where the "home" of each part of
derby's public API is. The current public API is not very clear in this regard
either, see e.g. http://db.apache.org/derby/javadoc/publishedapi/jdbc3/, but I
could try to clarify the jmx package(s) somewhat in this funcspec. As part of
the documentation effort, we should try to describe this in the package-summary
of the new package(s) and in other related Javadoc.
@Dan:
I suppose I was influenced by the current implementation when I specified a
different package for the Network Server MBean. This MBean was moved to the
drda package because of some packaging issue (according to comments in Jira),
but if keeping all MBeans in the same package is practically feasible I'm all
for it. Since the MBeans are not directly related to JDBC I'm reluctant to
putting the others in the o.a.d.jdbc package.
SystemMBean:
I see the point about exposing the derby.system.home property to JMX
clients, but I don't expect this to be a big issue, since when you enable JMX
monitoring of your JVM, you usually have access to lots of file system paths
anyway (library path, boot class path, etc.). One use case I think is valid is
the need to read this property in a setting where you are running Derby via
third-party tools (IDEs, application servers, db management tools etc.), and
you don't necessarily know the working directory of the VM running the Derby
system, or if derby.system.home has been set automatically by such a tool. One
way to find out where your databases (specified with relative paths) end up on
your file system is to check the value of derby.system.home.
MDatabaseMBean:
Not sure what the M stands for, to be honest. I was guessing "Managed
Database", but could be wrong. Perhaps the M should be removed unless someone
can shed some light on this.
SystemHome in MDatabaseMBean shouldn't be there. It's a bug in the
funcSpec - it's not available in the current implementation (patch 9).
The AuthenticatedAsUser attribute could use a better description, for
sure. It returns the user name of the user who has been authenticated through
JMX, i.e. the last valid user name supplied as parameter to the
authenticateAsUser() operation. If no user is authenticated through JMX, the
empty string is returned.
General:
I'll update the funcspec later this week. I intend to incorporate the above
feedback, but I also think some details are needed wrt. MBean naming and
(ObjectName) types and server domains.
Regarding the security issue mentioned in recent comments:
It could be argued that when you enable JMX management and monitoring you
explicitly expose your system for such access, and that if you want to control
this you need to enable JMX authentication (there is out-of-the-box support for
the use of password files and SSL, see
http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html ).
I noticed, however, a note about a potential security vulnerability wrt. JMX
password authentication with J2SE 5.0 (see the above link, look for "WARNING").
A bit more work (mimicking out-of-the-box management) is required for us to
work around this...
I came across a blog post [1] which has some details around this (see its
comments), and which includes example use cases wrt. JMX authentication and
authorization, which may be of help if we don't decide to settle with the
defaults. I've just skimmed through it so far, but perhaps someone familiar
with the current and soon-finished security features of Derby could take a look
at [1] and see if some kind of integration with existing features is desired
and feasible?
For the short run, however, I propose simply going with the defaults, as long
as we are clear about the risks.
[1]: http://blogs.sun.com/lmalventosa/entry/jmx_authentication_authorization
> Add JMX extensions to Derby
> ---------------------------
>
> Key: DERBY-1387
> URL: https://issues.apache.org/jira/browse/DERBY-1387
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Reporter: Sanket Sharma
> Assignee: John H. Embretsen
> Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff,
> DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff,
> DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip,
> DERBY-1387-7.zip, DERBY-1387-8.zip, DERBY-1387-9.diff, DERBY-1387-9.stat,
> derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, jmxFuncspec.html,
> jmxFuncspec.html, Requirements for JMX Updated.html, Requirements for
> JMX.html, Requirements for JMX.zip
>
>
> This is a draft requirement specification for adding monitoring and
> management extensions to Apache Derby using JMX. The requirements document
> has been uploaded on JIRA as well as the Derby Wiki page at
> http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
> Developers and Users are requested to please look at the document (feature
> list in particular) and add their own rating to features by adding a coloumn
> to the table.
> Comments are welcome.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
