Closed alexott closed 4 years ago
mxpr
is reusing JMX dacility from JDK so add all the stuff vanila JMX have is not a big deal.
Though, my intent for mxpr
was quick and dirty solution. If you want it right it would be probably better to setup JMX property on target JVM.
Am I missing some other useful cases for mxpr
I understand, I'm planning to use it as quick and dirty for solution when customer doesn't setup stuff in advance, and restarting/reconfiguring is not an option...
I'll look, if it's possible to do at all, and come with PR if I can :-)
Oh, one more think. You can do mxpr
work with jcmd
for JDK (no shady jars from internet required).
Here is my cheetsheet for JDK tools it has an example https://training.ragozin.info/collateral/JDK_tools_cheatsheet.pdf
jcmd
have all security options available.
The only issue with jcmd
- in some rare situations JVM RMI port on some their adapter making forwaring of JMX through SSH impossible. So I keep mxpr
for such cases.
Thank you very much for cheatsheet!
wont fix
it would be nice to add more security to
mxpr
, for example, ability to specify user name & password for remote connection.It would be also useful to add SSL, but it could be too much work.