gemmellr commented on PR #5028: URL: https://github.com/apache/activemq-artemis/pull/5028#issuecomment-2228031429
Sorry, I didnt see that you had commented. When we chatted about this previously and you mentioned you had already discussed with Gary/Dom and decided on adding it to the existing hawtio mbean, I didnt realise that specifically called itself out as a security mbean in its overall naming, so I can definitely see Justin's point there. Though as its not an MBean users really interact with themselves, I'm not sure how bad it would really be to go with it. I also thought their idea was better than adding a new MBean at the time because at least that existing MBean is already 'trusted' for the other stuff and was already clearly hawtio console specific, and this only really being a hawtio console problem. I didnt really want a new MBean for this either as its almost completely superfluous for every normal user, i.e most people simply dont need it so having an mbean for it feels like needless clutter for the regular case. It also needs a known domain and objectname to look up itself, which will almost certainly be something else that can clash with other things at some point. In retrospect this also only works for one broker 'jmx domain' at a time (same is true of using the existing hawtio mbean), which in some ways is odd as the entire reason this weird 'variable mbean jmx domain' stuff was added ~15 years ago was to support multiple broker being managed in the same VM using multiple different jmx domains. Thus far only 1 person has asked about hitting a mismatch here it seems, and that is only coming up because they are shading the broker. So to me it seems reasonable enough theyd also need to similarly update the console as well, which they already indicated theyd be up for doing with a custom build (since the bit needing changed is in a file in a jar, in the war) if that was the approach deemed necessary. I did suggest perhaps there is some way we could make that easier, e.g take the custom value from a specific file, which they could then more easily add/update/swap out than currently as part of the general console files themselves. I think I'm back to thinking that is preferable than mechanics like this to do it automatically. A specific new MBean for it, that doesnt even work for the original use case of varying the mbean domain, and is entirely superfluous for almost every user, feels like perhaps the worst option for auto-fixing a self-created problem from shading the broker but not similarly updating the console. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For additional commands, e-mail: gitbox-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact