6447048: Jconsole Best Practices for 6_10 and 7 (Message for Imalvent)

Question

doom despair and agony on me, deep dark ... you know the rest.
The very simple patch for pre-6_10, when fitted to the equivalent code in 6_10, no longer works!
Obviously the recognition of the containerView options and the extraction of the keys still works, but now, when these get added to the Dn token list (inside the Dn constructor now) they simply leave the MBean tab completely empty. Here is the code that does the work in the constructor:
if (isContainerView()) {
    //Containment model view
    List<String> list = extractContainmentDetails(keyPropertyList, mbean);
    for (String entry : list)
        tokens.add(new Token("key", entry));
else if (isTreeView()) ...(the code for extractContainmentDetails is essentially the same as in my previous post)
Which, as far as I can see, does the exact same thing as a) used to be done in my old fix and, b) is done for the tree view, EXCEPT that it breaks up the keys into sub-components - so the Tokens for, say, MBean
type=Server.Instance.Counters,Server=GtServerwould be
type=Server
name=GtServer
type=Instance
type=CountersPre 6_10, this produces the correct tree of:
+ Server
|
+ GtServer
  |
  + Attributes
  + Operations
  + Instance
    |
    + Attributes
    + Operations
    + Counters
      |
      + Attributes
      + OperationsI suspect that you are now using these "key" things in the Token list for accessing the MBeans and not simply for display, which is what was happening pre-6_10, and so the simple containment view change that I devised no-longer works!
I do understand that other fixes were needed for refresh etc - but I'm understandably disappointed that what was a simple structure change now seems to require something far more fundamental. Any suggestions on how I can take this forward?

Answer 1

And the problem is:
the method getHashKey in Dn searches for the substring of the value of the input token. The problem is that if any of the overall hash for the Dn contains that substring before the intended token, then the returned hash runs the risk of being a duplicate of another hash, and thus you get a bad insertion.
For me, my overall hash is
name=GtServer_1,type=ServerPool.Server,name=GtServer,type=ServerPool,domain=com.csc.gtmonitor.GtMonitor340so when we want the hash for
name=GtServerwe get the whole thing, rather than what we REALLY wanted, which was just the last part.
Suggestion 1:
Build the token hash keys as the Dn is being built by building up the hashkey string as each token is added. Requires change to Dn and Token so that Token has a hashkey property.
or Suggestion 2:
Change getHashKey to accept the token index and let it build the hash key from that index onward from the token list. Somewhat more expensive in that the hash is built up each time it is requested.
or Suggestion 3:
Change getHashKey to use a regular expression, and a terminating character of ", or end-of-string" on the end of the input token value. Still has a slight risk of trapping a substring that occurs earlier in the Dn hash than intended.
Opinions? (I like suggestion1 best)