db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: Choice of JMX implementations
Date Thu, 13 Jul 2006 22:46:42 GMT
Sanket Sharma wrote:
...
>> >     My recommendation is to use either XMOJO or MX4J. Both of them are
>> > open source and support JDK 1.3 and above, which is what Derby is
>> > supported on.
>> >
>> > Comments and opinion will be appriciated.
>> >
>> Is it necessary to choose a specific JMX implementation ? Aren't these
>> just implementations of the same JCP spec, so the interfaces/classes
>> should be compatible ?
> 
> 
> They are implementations of the same JCP and it is not really that big
> of an issue. The issues arises only when someone is using JDK < 1.5
> which does not carry a implementation by default. Since most of
> Derby's code is currently being built against JDK 1.3 and 1.4 (which
> do not carry such an implementation), it gave me a chance to look at
> alternatives and I just thought it will be good to discuss it.
> Currently, I'm experimenting with the reference implementation of JDK
> 6 which forces me to build my code against three different JDK's. It
> will be same for JDK1.5 as well. For building with JDK 1.4 and 1.3, I
> will need an implementation. Thats when the issue surfaces.
> Asking the user to download the reference implementation from Sun.com
> can be considered as an alternative.
> 
I understand.  I think it should be possible to build Derby with JMX 
features with JDK 1.4/1.3. To do it, we can ask the *developer*
to download a JMX library in the BUILDING.TXT instructions 
(http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.txt), or 
make a JMX library available from the svn repository.

Then, at a later point, we could decide if we want to distribute a JMX
library with Derby itself.

In terms of licensing, it seems like it is possible to redistribute mx4j
to end-users. This also probably means that we could put the mx4j jar
files into svn repository, so that developers do not need download them
manually.

Regards

Andreas

Mime
View raw message