Costin Manolache wrote:
Remy Maucherat wrote:
Dominik Drzewiecki wrote:
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.
Because they don't work with JDK1.4, and any people (including me) can't switch to Java5 since it breaks too much :-)
What are you talking about, it works great ;)
The option you mention are in fact the same thing with the webapp I'm suggesting - they have the effect of loading the standard javax.management.remote connector. The difference is that jx.m.r is using the standard API and will work with any JMX implementation, while
"com.sun" is specific to sun's implementation of jmx.
Right, the exact parameter will be proprietary. However, every VM will have to provide a JMX remote implementation, and I think it's rather obvious there will be some way to enable it with some option or config file.
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).Your post motivated me for trying jconsole, and I have to say it's really good.
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)
Yes, jconsole is the reason I wrote the app too. Plus the fact that mx4j2.0 no longer works with jkmx ( they dumped the connector beans from
distribution since they now support the standard jx.m.r )
I couldn't get the attach to process thing to work, though (= without a port). Is it supposed to be doable ?
As others have said, the problem with JkJMX is that it's annoying to keep it up to date. And when we had it up to date, the JMX client was then rarely up to date. So I'll let you guys decide what do do, but it's sort of obvious the need for that kind of stuff is a lot smaller than what it used to be for Tomcat 5.5.
Note: the main reason why I removed jk2.properties is because is has a very confusing name (again referring to mod_jk2); if it's really needed, then it should be renamed, or an alternate name should be allowed.
No, removing jk2.properties - and removing JkMX - is a good thing.
I'll check in the webapp code, it's easier to talk about code - if people don't like it, feel free to -1 :-)
+1 for that webapp. Actually, we should include it in the "compat" package, since that package is for JDK 1.4.
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
