You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Sanket Sharma <sa...@gmail.com> on 2006/07/13 20:28:15 UTC
Choice of JMX implementations
Just wanted an opinion about JMX implementation to use for Derby. I
have listed the better known implementations below with my comments:
1. Sun JDK 1.5 and above: Comes prepackaged with JMX. Requires no
additional Jars to depolyed with the client. Leads to smaller
footprint. One the negetive side, it will always require Derby to run
on JRE 1.5 and above. May not be a good choice as some implementations
might be using old JVM versions. For Sun JDK/JVM prior to version 1.5
Sun's references implemenation is available as a seperate jar
download. Applications running on JVM 1.3 and 1.4 will need to
download install this jar.
2. XMOJO Project: This JMX supports JDK version 1.2 and above,
which means it imposes no additional JDK requirements. Hoewever,
additional JARs will to be deployed on the client for them to use JMX.
They can either be bundled with Derby or can be seperately installed
on client. Another point to note is that XMojo itself requires more
jars to be present (xalan.jar, crimson.jar, and jaxp.jar and
org.mortbay.jetty.jar). It supports construction of MBeans through
Metadata sepcified in a XML file. Utility methods convert this
metadata in ModelMBeanInfo which can then be used to construct a
ModelMBean.
3. Apache Commons Modeller framework: The commons modelling
framework is another Apache project developed under the Jarkarta
project. Although, it is not an implementation in itself, it
facilitates writing of MBeans by using XML files. The Metadata for
MBeans is specified in an XML file which is parsed to gernerate
MBeans.It is known to work with all major JMX implementations.
4. MX4J: Another very popular JMX framework know to work with JDK
1.3 and above. It also supports automatic generation of ModelMBeans
using XDoclets. Needs additional jars to be deployed. Supports HTTP
adapters for access via HTTP.
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.
Best Regards,
Sanket Sharma
Re: Choice of JMX implementations
Posted by David Van Couvering <Da...@Sun.COM>.
I like the idea of detecting the presence of a JMX implementation and
starting the service if it exists. We'd still have to indicate exactly
what JMX implementations and versions we have tested with (and provide
links to the download page), so that users know what will work.
That said, if we *can* redistribute MX4J and we think it works well,
redistributing it would be a nice thing to do for our users, so they
don't have to take an extra step to be able to get JMX functionality for
Derby.
The nice thing is for anyone using JDK 1.5 or higher this is a non-issue.
What about J2ME, are there versions of J2ME that we support that don't
come with JMX, or are we covered?
Thanks,
David
Andrew McIntyre wrote:
> If the goal is to repackage any of these, I'm not sure that will be
> possible with any of the following, except for Apache Commons
> Modelling, but is that actually an implementation?
>
> For information on compatibility of other open source licenses with
> the ASL, see: http://people.apache.org/~cliffs/3party.html
>
> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
>> Just wanted an opinion about JMX implementation to use for Derby. I
>> have listed the better known implementations below with my comments:
>>
>> 1. For Sun JDK/JVM prior to version 1.5 Sun's references
>> implemenation is
>> available as a seperate jar download. Applications running
>> on JVM 1.3
>> and 1.4 will need to download install this jar.
>
> We can't repackage this jar, as the terms of Sun's BCL are
> incompatible with the ASL. But perhaps we could detect its presence
> and start the JMX services if an implementation is present.
>
>> 2. XMOJO Project
>
> This is GPL licensed. Currently ASF policy is not to redistribute
> GPL-licensed jars.
>
>> 3. Apache Commons Modeller framework
>
> Sounds like this would aid your development, but do you still need an
> implementation? At any rate, we could repackage it if its needed at
> runtime.
>
>> 4. MX4J
>
> This has a modified BSD license with an advertising clause, and a
> restriction to downstream projects on naming. Not that we'd ever name
> our project MX4J, but it's an extra restriction that isn't in the ASL,
> so we might need to get a determination from legal-discuss on whether
> this is acceptable to redistribute.
>
> andrew
Re: Choice of JMX implementations
Posted by Sanket Sharma <sa...@gmail.com>.
On 7/14/06, David Van Couvering <Da...@sun.com> wrote:
> Looks like we may have a winner... It would be interesting to see how
> they use it -- do they have it available only for pre-Java 5 VMs, or is
> it used regardless of what VM is being used?
It can be used regardless of the VM. Minimum requirement is Java 1.3.
On Java 1.5 and above, command line options can be used to give
precendence to MX4J libraries instead of Sun's libraries.
As of now, I'm testing my code against the reference implementation.
I'll take some more to evaluate the pros and cons of each of them
before actually making my changes permanent.
MX4J's jars - 399 KB for JMX implementation and 168 KB for remote
functionalities. The second one is not really needed right now.
>
> How big is the MX4J jar file?
> And what time is it in India, Sanket?
>
Its almost 5 AM! Time to go to bed :-) lol!!
Regards,
Sanket
Re: Choice of JMX implementations
Posted by David Van Couvering <Da...@Sun.COM>.
Looks like we may have a winner... It would be interesting to see how
they use it -- do they have it available only for pre-Java 5 VMs, or is
it used regardless of what VM is being used?
How big is the MX4J jar file?
And what time is it in India, Sanket?
David
Sanket Sharma wrote:
> Following apache projects are also known to use MX4J:
> Geronimo,
> Avalon-Phonenix
> Tomcat
>
> Regards,
> Sanket
>
> On 7/14/06, Jean T. Anderson <jt...@bristowhill.com> wrote:
>> thanks for checking the hivemind download, Andreas.
>>
>> I checked the geronimo.1.1 download and it does include the mx4j jars.
>> Its NOTICE file also has this attribution:
>>
>> >
>> =========================================================================
>> > == MX4J
>> Notice ==
>> >
>> =========================================================================
>> >
>> > This product includes software developed by the MX4J project
>> > (http://sourceforge.net/projects/mx4j).
>>
>>
>> -jean
>>
>>
>>
>> Andreas Korneliussen wrote:
>> > Jean T. Anderson wrote:
>> >
>> >> Andrew McIntyre wrote:
>> >>
>> >>> If the goal is to repackage any of these, I'm not sure that will be
>> >>> possible with any of the following, except for Apache Commons
>> >>> Modelling, but is that actually an implementation?
>> >>>
>> >>> For information on compatibility of other open source licenses with
>> >>> the ASL, see: http://people.apache.org/~cliffs/3party.html
>> >>>
>> >>> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
>> >>
>> >>
>> >> ...
>> >>
>> >>>> 4. MX4J
>> >>>
>> >>>
>> >>> This has a modified BSD license with an advertising clause, and a
>> >>> restriction to downstream projects on naming. Not that we'd ever name
>> >>> our project MX4J, but it's an extra restriction that isn't in the
>> ASL,
>> >>> so we might need to get a determination from legal-discuss on whether
>> >>> this is acceptable to redistribute.
>> >>
>> >>
>> >>
>> >> here's one precedent for using MX4J at apache (and there might be
>> more):
>> >>
>> >>
>> http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
>>
>> >>
>> >>
>> >>
>> > They are using it for development, and testing. However the users need
>> > to download mx4j themselves, or download another JMX
>> implementation, or
>> > use java 5.
>> >
>> > See http://jakarta.apache.org/hivemind/hivemind-jmx/quickstart.html
>> >
>> > I downloaded hivemind-1-1-1, and could not find any redistribution of
>> > mx4j there.
>> >
>> > Andreas
>> >
>> >
>> >> -jean
>> >>
>> >
>> >
>>
>>
Re: Choice of JMX implementations
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Sanket Sharma wrote:
> Following apache projects are also known to use MX4J:
> Geronimo,
> Avalon-Phonenix
> Tomcat
The Avalon project closed down, but Geronimo and Tomcat are both alive
and kicking.
-jean
[1] http://avalon.apache.org/closed.html
> Regards,
> Sanket
>
> On 7/14/06, Jean T. Anderson <jt...@bristowhill.com> wrote:
>
>> thanks for checking the hivemind download, Andreas.
>>
>> I checked the geronimo.1.1 download and it does include the mx4j jars.
>> Its NOTICE file also has this attribution:
>>
>> >
>> =========================================================================
>> > == MX4J
>> Notice ==
>> >
>> =========================================================================
>> >
>> > This product includes software developed by the MX4J project
>> > (http://sourceforge.net/projects/mx4j).
>>
>>
>> -jean
>>
>>
>>
>> Andreas Korneliussen wrote:
>> > Jean T. Anderson wrote:
>> >
>> >> Andrew McIntyre wrote:
>> >>
>> >>> If the goal is to repackage any of these, I'm not sure that will be
>> >>> possible with any of the following, except for Apache Commons
>> >>> Modelling, but is that actually an implementation?
>> >>>
>> >>> For information on compatibility of other open source licenses with
>> >>> the ASL, see: http://people.apache.org/~cliffs/3party.html
>> >>>
>> >>> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
>> >>
>> >>
>> >> ...
>> >>
>> >>>> 4. MX4J
>> >>>
>> >>>
>> >>> This has a modified BSD license with an advertising clause, and a
>> >>> restriction to downstream projects on naming. Not that we'd ever name
>> >>> our project MX4J, but it's an extra restriction that isn't in the
>> ASL,
>> >>> so we might need to get a determination from legal-discuss on whether
>> >>> this is acceptable to redistribute.
>> >>
>> >>
>> >>
>> >> here's one precedent for using MX4J at apache (and there might be
>> more):
>> >>
>> >>
>> http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
>>
>> >>
>> >>
>> >>
>> > They are using it for development, and testing. However the users need
>> > to download mx4j themselves, or download another JMX
>> implementation, or
>> > use java 5.
>> >
>> > See http://jakarta.apache.org/hivemind/hivemind-jmx/quickstart.html
>> >
>> > I downloaded hivemind-1-1-1, and could not find any redistribution of
>> > mx4j there.
>> >
>> > Andreas
>> >
>> >
>> >> -jean
>> >>
>> >
>> >
>>
>>
>
Re: Choice of JMX implementations
Posted by Sanket Sharma <sa...@gmail.com>.
Following apache projects are also known to use MX4J:
Geronimo,
Avalon-Phonenix
Tomcat
Regards,
Sanket
On 7/14/06, Jean T. Anderson <jt...@bristowhill.com> wrote:
> thanks for checking the hivemind download, Andreas.
>
> I checked the geronimo.1.1 download and it does include the mx4j jars.
> Its NOTICE file also has this attribution:
>
> > =========================================================================
> > == MX4J Notice ==
> > =========================================================================
> >
> > This product includes software developed by the MX4J project
> > (http://sourceforge.net/projects/mx4j).
>
>
> -jean
>
>
>
> Andreas Korneliussen wrote:
> > Jean T. Anderson wrote:
> >
> >> Andrew McIntyre wrote:
> >>
> >>> If the goal is to repackage any of these, I'm not sure that will be
> >>> possible with any of the following, except for Apache Commons
> >>> Modelling, but is that actually an implementation?
> >>>
> >>> For information on compatibility of other open source licenses with
> >>> the ASL, see: http://people.apache.org/~cliffs/3party.html
> >>>
> >>> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
> >>
> >>
> >> ...
> >>
> >>>> 4. MX4J
> >>>
> >>>
> >>> This has a modified BSD license with an advertising clause, and a
> >>> restriction to downstream projects on naming. Not that we'd ever name
> >>> our project MX4J, but it's an extra restriction that isn't in the ASL,
> >>> so we might need to get a determination from legal-discuss on whether
> >>> this is acceptable to redistribute.
> >>
> >>
> >>
> >> here's one precedent for using MX4J at apache (and there might be more):
> >>
> >> http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
> >>
> >>
> >>
> > They are using it for development, and testing. However the users need
> > to download mx4j themselves, or download another JMX implementation, or
> > use java 5.
> >
> > See http://jakarta.apache.org/hivemind/hivemind-jmx/quickstart.html
> >
> > I downloaded hivemind-1-1-1, and could not find any redistribution of
> > mx4j there.
> >
> > Andreas
> >
> >
> >> -jean
> >>
> >
> >
>
>
Re: Choice of JMX implementations
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
thanks for checking the hivemind download, Andreas.
I checked the geronimo.1.1 download and it does include the mx4j jars.
Its NOTICE file also has this attribution:
> =========================================================================
> == MX4J Notice ==
> =========================================================================
>
> This product includes software developed by the MX4J project
> (http://sourceforge.net/projects/mx4j).
-jean
Andreas Korneliussen wrote:
> Jean T. Anderson wrote:
>
>> Andrew McIntyre wrote:
>>
>>> If the goal is to repackage any of these, I'm not sure that will be
>>> possible with any of the following, except for Apache Commons
>>> Modelling, but is that actually an implementation?
>>>
>>> For information on compatibility of other open source licenses with
>>> the ASL, see: http://people.apache.org/~cliffs/3party.html
>>>
>>> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
>>
>>
>> ...
>>
>>>> 4. MX4J
>>>
>>>
>>> This has a modified BSD license with an advertising clause, and a
>>> restriction to downstream projects on naming. Not that we'd ever name
>>> our project MX4J, but it's an extra restriction that isn't in the ASL,
>>> so we might need to get a determination from legal-discuss on whether
>>> this is acceptable to redistribute.
>>
>>
>>
>> here's one precedent for using MX4J at apache (and there might be more):
>>
>> http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
>>
>>
>>
> They are using it for development, and testing. However the users need
> to download mx4j themselves, or download another JMX implementation, or
> use java 5.
>
> See http://jakarta.apache.org/hivemind/hivemind-jmx/quickstart.html
>
> I downloaded hivemind-1-1-1, and could not find any redistribution of
> mx4j there.
>
> Andreas
>
>
>> -jean
>>
>
>
Re: Choice of JMX implementations
Posted by Andreas Korneliussen <An...@Sun.COM>.
Jean T. Anderson wrote:
> Andrew McIntyre wrote:
>
>>If the goal is to repackage any of these, I'm not sure that will be
>>possible with any of the following, except for Apache Commons
>>Modelling, but is that actually an implementation?
>>
>>For information on compatibility of other open source licenses with
>>the ASL, see: http://people.apache.org/~cliffs/3party.html
>>
>>On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
>
> ...
>
>>> 4. MX4J
>>
>>This has a modified BSD license with an advertising clause, and a
>>restriction to downstream projects on naming. Not that we'd ever name
>>our project MX4J, but it's an extra restriction that isn't in the ASL,
>>so we might need to get a determination from legal-discuss on whether
>>this is acceptable to redistribute.
>
>
> here's one precedent for using MX4J at apache (and there might be more):
>
> http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
>
>
They are using it for development, and testing. However the users need
to download mx4j themselves, or download another JMX implementation, or
use java 5.
See http://jakarta.apache.org/hivemind/hivemind-jmx/quickstart.html
I downloaded hivemind-1-1-1, and could not find any redistribution of
mx4j there.
Andreas
> -jean
>
Re: Choice of JMX implementations
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Andrew McIntyre wrote:
> If the goal is to repackage any of these, I'm not sure that will be
> possible with any of the following, except for Apache Commons
> Modelling, but is that actually an implementation?
>
> For information on compatibility of other open source licenses with
> the ASL, see: http://people.apache.org/~cliffs/3party.html
>
> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
...
>
>> 4. MX4J
>
> This has a modified BSD license with an advertising clause, and a
> restriction to downstream projects on naming. Not that we'd ever name
> our project MX4J, but it's an extra restriction that isn't in the ASL,
> so we might need to get a determination from legal-discuss on whether
> this is acceptable to redistribute.
here's one precedent for using MX4J at apache (and there might be more):
http://jakarta.apache.org/hivemind/hivemind-jmx/setupJMXImplementation.html
-jean
Re: Choice of JMX implementations
Posted by Sanket Sharma <sa...@gmail.com>.
Thanks Andrew for pointing out the legal implications.
Apache commons is not an implementation. It only facilitates coding of MBeans.
On 7/14/06, Andrew McIntyre <mc...@gmail.com> wrote:
> If the goal is to repackage any of these, I'm not sure that will be
> possible with any of the following, except for Apache Commons
> Modelling, but is that actually an implementation?
>
> For information on compatibility of other open source licenses with
> the ASL, see: http://people.apache.org/~cliffs/3party.html
>
> On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
> > Just wanted an opinion about JMX implementation to use for Derby. I
> > have listed the better known implementations below with my comments:
> >
> > 1. For Sun JDK/JVM prior to version 1.5 Sun's references implemenation is
> > available as a seperate jar download. Applications running on JVM 1.3
> > and 1.4 will need to download install this jar.
>
> We can't repackage this jar, as the terms of Sun's BCL are
> incompatible with the ASL. But perhaps we could detect its presence
> and start the JMX services if an implementation is present.
Maybe we can put it under "Required Software" in the Derby INSTALL and
BUILD document? or we can make the entire service optional? If the
user is aware of requirements and wants to use JMX, either he can
install JRE1.5 and above or download the jar, set the classpath and
start application with command line option to start the JMX modules?
We specify the details in BUILD and INSTALL documents, the way BUILD
document guides a user to download JCE and other optional components.
> > 3. Apache Commons Modeller framework
>
> Sounds like this would aid your development, but do you still need an
> implementation? At any rate, we could repackage it if its needed at
> runtime.
Yes, I will still require an implementation.
>
> > 4. MX4J
>
> This has a modified BSD license with an advertising clause, and a
> restriction to downstream projects on naming. Not that we'd ever name
> our project MX4J, but it's an extra restriction that isn't in the ASL,
> so we might need to get a determination from legal-discuss on whether
> this is acceptable to redistribute.
I was not really aware of the legal implications and would like to
thank you for it. I will read the Apache license terms and revert back
in a while.
Best Regards
Sanket.
Re: Choice of JMX implementations
Posted by Andrew McIntyre <mc...@gmail.com>.
If the goal is to repackage any of these, I'm not sure that will be
possible with any of the following, except for Apache Commons
Modelling, but is that actually an implementation?
For information on compatibility of other open source licenses with
the ASL, see: http://people.apache.org/~cliffs/3party.html
On 7/13/06, Sanket Sharma <sa...@gmail.com> wrote:
> Just wanted an opinion about JMX implementation to use for Derby. I
> have listed the better known implementations below with my comments:
>
> 1. For Sun JDK/JVM prior to version 1.5 Sun's references implemenation is
> available as a seperate jar download. Applications running on JVM 1.3
> and 1.4 will need to download install this jar.
We can't repackage this jar, as the terms of Sun's BCL are
incompatible with the ASL. But perhaps we could detect its presence
and start the JMX services if an implementation is present.
> 2. XMOJO Project
This is GPL licensed. Currently ASF policy is not to redistribute
GPL-licensed jars.
> 3. Apache Commons Modeller framework
Sounds like this would aid your development, but do you still need an
implementation? At any rate, we could repackage it if its needed at
runtime.
> 4. MX4J
This has a modified BSD license with an advertising clause, and a
restriction to downstream projects on naming. Not that we'd ever name
our project MX4J, but it's an extra restriction that isn't in the ASL,
so we might need to get a determination from legal-discuss on whether
this is acceptable to redistribute.
andrew
Re: Choice of JMX implementations
Posted by Andreas Korneliussen <An...@Sun.COM>.
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
Re: Choice of JMX implementations
Posted by Sanket Sharma <sa...@gmail.com>.
> I think that the RI of JMX also has HttpAdaptor.
It was released as part of sun.* packages which are not officially
supported by sun. And I think it has been removed from JDK 6, not very
sure though.
> > 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 might recommend using the reference implementation during the
> development of this feature, because then you may avoid being dependent
> on specific add-on features from a specific library. Or is there a
> specific feature you really would like to use, which is not available in
> the RI ?
No feature in particular that I would like to use. I will use only
standard features defined in the corresponding JCP. The only issue in
my opinion was my JMX implementation was adding the requirement for a
third version of JDK.
>
> XMOJO is distributed under LGPL, could that be a problem ?
Will check with Apache licence and revert back.
Regards,
Sanket
>
> Sincerely
> -- Andreas
>
>
Re: Choice of JMX implementations
Posted by Andreas Korneliussen <An...@Sun.COM>.
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:
>
> 1. Sun JDK 1.5 and above: Comes prepackaged with JMX. Requires no
> additional Jars to depolyed with the client. Leads to smaller
> footprint. One the negetive side, it will always require Derby to run
> on JRE 1.5 and above. May not be a good choice as some implementations
> might be using old JVM versions. For Sun JDK/JVM prior to version 1.5
> Sun's references implemenation is available as a seperate jar
> download. Applications running on JVM 1.3 and 1.4 will need to
> download install this jar.
>
> 2. XMOJO Project: This JMX supports JDK version 1.2 and above,
> which means it imposes no additional JDK requirements. Hoewever,
> additional JARs will to be deployed on the client for them to use JMX.
> They can either be bundled with Derby or can be seperately installed
> on client. Another point to note is that XMojo itself requires more
> jars to be present (xalan.jar, crimson.jar, and jaxp.jar and
> org.mortbay.jetty.jar). It supports construction of MBeans through
> Metadata sepcified in a XML file. Utility methods convert this
> metadata in ModelMBeanInfo which can then be used to construct a
> ModelMBean.
>
> 3. Apache Commons Modeller framework: The commons modelling
> framework is another Apache project developed under the Jarkarta
> project. Although, it is not an implementation in itself, it
> facilitates writing of MBeans by using XML files. The Metadata for
> MBeans is specified in an XML file which is parsed to gernerate
> MBeans.It is known to work with all major JMX implementations.
>
> 4. MX4J: Another very popular JMX framework know to work with JDK
> 1.3 and above. It also supports automatic generation of ModelMBeans
> using XDoclets. Needs additional jars to be deployed. Supports HTTP
> adapters for access via HTTP.
>
I think that the RI of JMX also has HttpAdaptor.
> 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 ?
I might recommend using the reference implementation during the
development of this feature, because then you may avoid being dependent
on specific add-on features from a specific library. Or is there a
specific feature you really would like to use, which is not available in
the RI ?
XMOJO is distributed under LGPL, could that be a problem ?
Sincerely
-- Andreas
> Best Regards,
> Sanket Sharma
Re: Choice of JMX implementations
Posted by David Van Couvering <Da...@Sun.COM>.
That doesn't *look* like a JMX implementation, but a set of utilities on
top of JMX. Nice idea, though.
David
Jean T. Anderson 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:
>
> is Geronimo an option?
>
> http://geronimo.apache.org/api/org/apache/geronimo/kernel/jmx/package-summary.html
>
> -jean
Re: Choice of JMX implementations
Posted by Sanket Sharma <sa...@gmail.com>.
Nope.
Geronimo is an application server built around JMX sort of architecture.
On 7/14/06, Jean T. Anderson <jt...@bristowhill.com> 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:
>
> is Geronimo an option?
>
> http://geronimo.apache.org/api/org/apache/geronimo/kernel/jmx/package-summary.html
>
> -jean
>
Re: Choice of JMX implementations
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
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:
is Geronimo an option?
http://geronimo.apache.org/api/org/apache/geronimo/kernel/jmx/package-summary.html
-jean
Re: Choice of JMX implementations
Posted by David Van Couvering <Da...@Sun.COM>.
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.
>>
Re: Choice of JMX implementations
Posted by David Van Couvering <Da...@Sun.COM>.
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.
>
Re: Choice of JMX implementations
Posted by Daniel John Debrunner <dj...@apache.org>.
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.