>> Hi, >> >> Not sure what's the new policy for loading the Jmx RMI connector. >> jk2.properties was a hack - and now that it is removed, I was >> wandering if >> we have any "official" mechanism. >> > > At the moment, jk2.properties is still used (we're just not shipping the > > default one). It should be possible to configure JkMX via Connector > attributes. > >> I had a small class that hooked in the connector, and I now refactored >> it >> to a webapp - nothing fancy ( it's not even "trusted" ), only loads >> rmiregistry and the jmx connector. I can check it in if there's no >> other >> mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 >> there >> are the cli options )
Why don't we dump the JkMX and just settle for the facilities provided by Java 5 configurable via standard system properties: -Dcom.sun.management.jmxremote alone for local JVM monioring or -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false for remote machine monitoring. I checked both myself with jconsole shipped with Java 5. It works like a charm (apart from increased CPU Load on the machine the jconsole runs). MC4J 1.2 B5 has no problems with attaching to remote JVM either, hovewer it has some issues with mbeans provided by JVM, MC4J folks are aware of. The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know there is number of users wishing to run tomcat on JVM <1.5) cheers, /dd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
