db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Tue, 19 Feb 2008 16:00:48 GMT

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

John H. Embretsen commented on DERBY-1387:
------------------------------------------

I have a couple of questions related to the building and packaging of MBeans:

1) All MBean interfaces are placed in the package org.apache.derby.mbeans. All the current
classes in this package are included in derby.jar. If someone creates MBeans that are designed
to manage or monitor a part of derby that is in a different jar file, e.g. the Network Server
(derbynet.jar) or IJ (derbytools.jar), we have a number of options:

    a) Keep the interface in the same jar as the class(es) referencing the interface. This
means that MBean interfaces in org.apache.derby.mbeans may be placed in a number of different
jar files.
    b) Keep all MBean interfaces in one jar, namely derby.jar.
    c) Include the interface in both derby.jar and the jar which code references the interface.

  I believe a) is the default today. For example, adding a NetworkServer MBean will result
in its interface being included in derbynet.jar only. The org.apache.derby.mbeans package
would have to be "unsealed". 

  Is this the way to proceed, or should we rather pursue option b) or c)?


2) MBean implementations such as Version and JDBC are compiled with jdk1.4 today. This means
that those classes cannot reference the JMX API directly. I wouldn't be surprised if we at
some point would like to utilize the JMX notification scheme with some MBeans, or include
various MBean metadata to improve usability. This might require access to the JMX API from
such classes.
I would suspect that changing this (to build such MBean implementations with jdk1.5) will
require solving a few non-trivial build dependency issues. Is this a valid concern, or do
I worry too much?
 


> 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, derby1387_simple_9_1.txt, derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html,
jmxFuncspec.html, jmxFuncspec.html, jmxPolicyFileChanges_v1.diff, 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.


Mime
View raw message