db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Choice of JMX implementations
Date Thu, 13 Jul 2006 20:06:15 GMT
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 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.

View raw message