I've got a good number of nits and bugs I'd like to get off my chest...
1) The description area shows HTML tags -- rather than HTML.
2) When one has an MBean with ObjectName 'foo:a=a1,b=b1' and another with ObjectName 'foo:a=a1,b=b1,c=c1', then jconsole (nicely) shows the former as the parent tree node of the latter. In MC4J's hierarchical view they're shown as siblings both under the parent a=a1 which is, in turn under a parent of b=b1!! This is very confusing and far from what a user would expect.
3) The JVM dashboards do not function properly when one has multiple MBean instances of type sun.management.MemoryImpl, etc (i.e. the built-in Java 5 singletons) registered in one's MBeanServer. This might seem like an invalid use case, but I have a server-side JVM containing its own MBeans and proxying all the MBeans from a number of other JVMs (under uniquely namespaced ObjectNames, of course). jconsole handles this fine, but MC4J's pie chart goes beserk, the threading dashboard gives an ArrayIndexOutOfBounds, etc. I'd suggest limiting the global dashboards of these types to the java.lang domain and then allow application of these dashboards to beans of these types on demand via contextual menus.
4) MC4J shows CompositeData operation results as strings (ala toString()), whereas jconsole produces a nice CompositeData browsing window.
5) Neither MC4J nor jconsole seems to give nice viewing of CompositeData[] attributes. [Yes, I had provided the proper return type in my MBeanInfo.] I had to use TabularData instead -- but that resulted in the CompositeData being ordered by hash code of Object[new Integer(intIndex)] rather than by intIndex.
6) MC4J has no handy table of local 'jps' style connections that are available like jconsole.
Also, is it easy to completely hide "Unregister MBean"? I don't ever want users to be able to do this from the management console! This is something they should use my MBean operations for or take into their own hands by writing code. This is too monumental of an operation to just leave hanging out by default! [Maybe if the relationship service was *easy* to use and fathom one could enforce appropriate cardinality and integrity, but I'm not convinced as this could involve MBean logic.]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also on (3), feedback from users seems to indicate that an option to show graphs for all memory beans in one view with labels on each graph, i.e. so one can compare what's going on in each at various points in time, etc. is quite desirable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, along the lines of (5), column header sorting of TabularData displays is highly desirable. It would also be nice if by default the index keys were used as primary, secondary, etc, sorting keys -- or at least there was an option for this. Hash order display by the Object[] of keys is not very useful...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, dead wouldn't be the right term, but unintended hiatus would be fair enough. I've had a busy time this year, moving, becoming a father and changing jobs so that MC4J development has certainly lacked a concerted effort.
I am pushing slowly towards a 2.0 release though with a newer, simpler architecture and actually have addressed some of your listed issues already. Because its such a big change, the work has been going on in a branch and really isn't ready to even be previewed yet. Hope to have news soon though... Sometime this year.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greg, thanks a lot for your work that you've already done.
And I think many people are watching this projects and waiting for the future works on this great JMX tool! ;)
I wish you to manage all you problems and hopefully gladden us soon with version 2.0 ;)
Cheers!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've got a good number of nits and bugs I'd like to get off my chest...
1) The description area shows HTML tags -- rather than HTML.
2) When one has an MBean with ObjectName 'foo:a=a1,b=b1' and another with ObjectName 'foo:a=a1,b=b1,c=c1', then jconsole (nicely) shows the former as the parent tree node of the latter. In MC4J's hierarchical view they're shown as siblings both under the parent a=a1 which is, in turn under a parent of b=b1!! This is very confusing and far from what a user would expect.
3) The JVM dashboards do not function properly when one has multiple MBean instances of type sun.management.MemoryImpl, etc (i.e. the built-in Java 5 singletons) registered in one's MBeanServer. This might seem like an invalid use case, but I have a server-side JVM containing its own MBeans and proxying all the MBeans from a number of other JVMs (under uniquely namespaced ObjectNames, of course). jconsole handles this fine, but MC4J's pie chart goes beserk, the threading dashboard gives an ArrayIndexOutOfBounds, etc. I'd suggest limiting the global dashboards of these types to the java.lang domain and then allow application of these dashboards to beans of these types on demand via contextual menus.
4) MC4J shows CompositeData operation results as strings (ala toString()), whereas jconsole produces a nice CompositeData browsing window.
5) Neither MC4J nor jconsole seems to give nice viewing of CompositeData[] attributes. [Yes, I had provided the proper return type in my MBeanInfo.] I had to use TabularData instead -- but that resulted in the CompositeData being ordered by hash code of Object[new Integer(intIndex)] rather than by intIndex.
6) MC4J has no handy table of local 'jps' style connections that are available like jconsole.
Also, is it easy to completely hide "Unregister MBean"? I don't ever want users to be able to do this from the management console! This is something they should use my MBean operations for or take into their own hands by writing code. This is too monumental of an operation to just leave hanging out by default! [Maybe if the relationship service was *easy* to use and fathom one could enforce appropriate cardinality and integrity, but I'm not convinced as this could involve MBean logic.]
Gary:
Any progress on any of this?
Also on (3), feedback from users seems to indicate that an option to show graphs for all memory beans in one view with labels on each graph, i.e. so one can compare what's going on in each at various points in time, etc. is quite desirable.
Also, along the lines of (5), column header sorting of TabularData displays is highly desirable. It would also be nice if by default the index keys were used as primary, secondary, etc, sorting keys -- or at least there was an option for this. Hash order display by the Object[] of keys is not very useful...
Is MC4J dead?
I do not see any progress on 1.2b9's issues -- either via a 1.2b10 or a 1.3 alpha...
Well, dead wouldn't be the right term, but unintended hiatus would be fair enough. I've had a busy time this year, moving, becoming a father and changing jobs so that MC4J development has certainly lacked a concerted effort.
I am pushing slowly towards a 2.0 release though with a newer, simpler architecture and actually have addressed some of your listed issues already. Because its such a big change, the work has been going on in a branch and really isn't ready to even be previewed yet. Hope to have news soon though... Sometime this year.
Greg, thanks a lot for your work that you've already done.
And I think many people are watching this projects and waiting for the future works on this great JMX tool! ;)
I wish you to manage all you problems and hopefully gladden us soon with version 2.0 ;)
Cheers!