https://issues.apache.org/bugzilla/show_bug.cgi?id=40728
--- Comment #6 from Jess Holle <je...@ptc.com> 2011-05-01 13:51:58 UTC --- I believe it is important to be able to get to data that would be of interest from jconsole/VisualVM. This means more than just being Serializable. It also means sticking to classes that are built into the JDK and classes that jconsole/VisualVM do a decent job of displaying. *Ideally* this means sticking to so called "open" MBean types (primitives [and object versions thereof], Strings, Dates, ObjectNames, CompositeData, TabularData, and arrays of any dimension of any of these). In Java 6 and higher if you use MXBeans then one can have CompositeData automatically produced for other classes automatically if your classes follow certain rules. All that said, there are inevitably some attributes that are useful in-process or even by specialized remote clients that one wishes to convey with other types. Unless the MXBean trick works for you in the case in question, this means breaking the rules with some attributes. That's fine as long as those attributes aren't really interesting in jconsole/VisualVM *or* you provide alternative attribute(s) for use by jconsole/VisualVM. I'm commenting here based on Mark's request for review and votes where appropriate. I'm tempted to vote on this -- but would not do so if the resulting action was merely to remove MBean attributes that are not serializable. I also do not have a sense for how many attributes that would be of interest in jconsole/VisualVM currently have no useful representation there. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
