I want to retract my statement about removing support for system
properties, major backward compatibility issue, what was I thinking?
I *can* see, however, that system properties become a layer on top of a
core JMX implementation, so that internally the only way the system is
configured and managed is through the JMX service. But this really
shouldn't happen until JMX is "just there" for all VMs that we support,
I agree with Dan it would not be good to *require* a separate JMX jar
file for Derby to run.
That said, I think the advantages of JMX are significant enough that
many people will want to use it, and I think there's value in
redistributing MX4J if we think it's up to snuff.
David
David Van Couvering wrote:
My understanding from Sanket's design is it uses the module
architecture, so it's pluggable, and that it isn't even started by
default, you have to enable it. No new requirements on Derby unless you
*want* to use JMX.
I would argue, however, that we should keep open to over time JMX
becoming the primary configuration and management framework. Supporting
both JMX and system properties may become a bit time-consuming over
time. Perhaps, for example, when we EOL JDK 1.4 support, so that JMX
is "just there" and doesn't require a separate runtime jar file.
David
Daniel John Debrunner wrote:
Sanket Sharma wrote:
Just wanted an opinion about JMX implementation to use for Derby. I
have listed the better known implementations below with my comments:
[snip]
Comments and opinion will be appriciated.
Sounds like a pluggable JMX implementation would be best, rather than
forcing an infrastructure on a derby user.
I hope that the JMX stuff is optional, and I can continue to run Derby
without any JMX booting or requiring any JMX libraries.
Thanks,
Dan.
