JMX4Ant is an open source project comprised of optional Ant tasks that allows interactions with JMX MBeans; It was created to provide tasks for J2EE resource creation and management from Ant that developers use to build/deploy application (e.g. create a JDBC pool and JMS queues/topics before deploying entity and message driven beans).
Check out http://jmx4ant.sourceforge.net/
You might also want to track the Jakarta Commons Modeler
project which also includes a set of Ant tasks for working with MBeans. Its used quite extensively on Tomcat 5.0. Maybe you could merge your work together into a single open source project?
I believe the two projects have different goals but are complimentary.
Jakarta Commons Modeler provides tools to develop new JMX MBeans implementations.
JMX4Ant provides tools to use JMX MBeans implementations that are deployed (i.e. runtime accessible) within a JMX server.
Here's a scenario to make things clearer.
If I was developing a new application ("foo-app") and thought that providing a set of MBeans to allow others to manage my slick new application would be cool, I might use Jakarta Commons Modeler to make my life easier in implmenting those MBeans.
On the other hand, if I was an administer of "foo-app" and wanted to use those MBeans from ANT, then I could use JMX4Ant tasks for that purpose.
Hope that clarifies things, and my apologies in advance if I've misinterpreted the goals of Jakarta commons-modeler.
I didn't get the following explanation:
> On the other hand, if I was an administer of "foo-app" and wanted to use those MBeans from ANT, then I could use JMX4Ant tasks for that purpose.
> Hope that clarifies things, and my apologies in advance if I've misinterpreted the goals of Jakarta commons-modeler.
How specifically would a system admin want to use the MBeans from ANT? I'm actually pretty familiar with WLS MBeans and we've written our own application MBeans for configuration and runtime but I've never thought about how I'd want to access them from ANT. Could you give a more specific example?
Sure, I'll try a couple of further examples and see if one sticks.
Often, system adminstrators need to perform routine adminstrative procedures on application that can benefit from being "scripted".
For example, every day at 9:30 AM (e.g. peak load period), the admin may want to check to see how many connections are used in a JDBC connection pool. If the value is unexpectedly high, the admin may need to take some appropriate action (increase the # of connections) or may wish to be alerted via email.
To solve this problem, an Ant script could retrieve the number of currently used JDBC connections using JMX4Ant's <configureMBean> task. The retrieved value is stored in a Ant property, which can then be used elsewhere in the Ant script (e.g. in the body of an email sent using the ant <mail> task).
Of course, this admin scenario is just one example.
A J2EE developer might also use JMX4Ant to automatically create resources her J2EE application is dependent on. This is just another variation on what it means to "administer" a J2EE server.
For example, she may be deploying a MessageDrivenBean which is listening on a specific JMS queue. This developer could write a simple Ant script to create the JMS queue (or just check to see if the queue exists). This script could then be run prior to other Ant targets that would deploy her application. Putting her energy into writing that Ant script would save effort and reduce errors each time that application was deployed to a new development, testing, or production J2EE server.
I may be completely off-base here, but it sounds like another creative use for Ant was developed. This time as an admin tool interfacing with MBeans.
just my $0.02...
My original motiviation was to allow for automated creation of resources that J2EE components I was developing depended upon.
Creating my J2EE resources from Ant made sense since all my compile/ejbc/deploy stuff was already being done through Ant. The real pain came whenever someone else (another developer or tester) would try to deploy my J2EE component. The deployment would frequently fail because the resources I was dependent on were not created, or not created properly. Even when carefully documented procedures were provided with my component as to which J2EE resources were required, human error could often result in unecessary extra effort.
The daily admin tasks example I provided earlier in this thread is really just another way to look at the problem of automating the management of J2EE applications. There are probably other, far superior, tools than Ant for that job I'm sure, but Ant seems to be flexible enought to accomodate that scenario. In any case, I would be very surprised if I was the first person to imagine that Ant could be a helpful tool to administrators.
Thanks for the further explanation. I hadn't thought of using Ant in this way. I typically think of this as the space for products like Panacya, Dirig, etc that have JMX monitoring capabilities and in the case of Dirig can invoke JMX methods to change attributes like the connection pool sizes. In this case these tools are exposing & monitoring the JMX enabled components within WLS. One of the nice attributes of WLS is that everything is either a configuration, runtime or admin MBean.