ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [SUBMIT] AntJMX
Date Tue, 13 Aug 2002 22:24:00 GMT
Posting this email trail as it some of the same issues that have come up in
other postings plus some additional suggestions.


-----Original Message-----
From: Dueck, Brian 
Sent: Tuesday, August 13, 2002 4:55 PM
Subject: RE: [SUBMIT] AntJMX

Yup, get the <mbean> idea. Great suggestion. That'll probably make an
appearance shortly.

Thanks again.


-----Original Message-----
Sent: Tuesday, August 13, 2002 4:35 PM
To: ''
Subject: RE: [SUBMIT] AntJMX

OK. Makes sense, at least on the implementation side, since indeed Ant
doesn't play well with more than two levels of elements (the tasks, and it's
sub-element). On the other hand, the top-level <jmx> could be a container
task that restricts its contained tasks to the JMX-related tasks.

About the <MBean> datatype, from your example I assumed that you would have
to re-specify the name/serverType/user/password attribute to all JMX related
tasks to access the same MBean. So instead of repeating this info (even
though you can centralize some of it with properties), you could do

<MBean id="mybean"
       password="secret" />

<configureMBean mbeanref="mybean"

<showMBean mbeanref="mybean"
           ... />

i.e. reuse the information about the MBean in several JMX tasks. --DD

-----Original Message-----
From: [] 
Sent: Tuesday, August 13, 2002 3:11 PM
Subject: RE: [SUBMIT] AntJMX

Good feedback - thanks!

I actually started out with that exact approach, but things got messy rather
quickly both from an ant script and implementation perspective.

The reasons I rejected this approach (after having had most of it
implemented) were:

1. Difficult to write the XML for users. This is because there ended up
being too many nested elements <jmx><configure><setAttribute> - most ant
tasks seem to only do 2 levels of nesting, to do what I wanted, I'd need
three levels.
2. Ambigious behaviour if I allowed users to specify multiple jmx actions
underneath the <jmx> element - what order do I perform these in? What
happens with inputs/outputs.
3. failOnError behaviour was trickier to implement.
4. Code structure maintenance - with only one master <jmx> task it ended up
being one complex task vs. several nice little modular ones. Maybe there was
a way around this, but I couldn't figure it out.

Hadn't thought of the <mbean> datatype idea - could you explain what you


-----Original Message-----
Sent: Tuesday, August 13, 2002 4:03 PM
To: ''
Subject: RE: [SUBMIT] AntJMX

Don't know that much about JMX and MBeans, but I was thinking that having a
single <jmx> task with several 'action' sub-element might be better!?!? It
would allow the documentation of the task to not be spread tomany tasks. I
suppose all your current tasks share quite a bit of attribute/element to
specify which MBean to connect to, so maybe a <mbean> datatype that could be
referenced from your various tasks could be useful too. I'm just thinking
out loud, and since mostly ignorant of the subject, probably for nothing...


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message