ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Project.toXML() ?
Date Mon, 14 Oct 2002 00:53:36 GMT
David Jencks wrote:

> Saving changes in your mbeans is IMO best handled by using a jmx and
> modelmbean implementation that implements persistence.  Writing out
> something like the original xml config file is more or less disasterous:
> after trying it in jboss 2.2 we will never go back.

I'll have to disagree with this :-) 

I agree that (runtime) changes should be done via a JMX, but 
JMX is (IMO) a pretty bad persistence API, and I don't thing 
that configuration should be restricted to runtime ( in 
JMX-handles-persistence you do need the MBeans instantiated and 
in a certain state - it works very well for modifying a running
server, but sometimes it's a bit of foreced solution if you 
want to modify passive config ).

I agree that 'original xml' can't be completely preserved, and comments 
and some other structures are hard. 

At least the solution that we are trying ( or at least I'm trying )for 
tomcat5 is a 2-layer, with config handled by JNDI and runtime changes
handled by JMX. It should be possible to change the port of tomcat using
a simple ant task ( and without starting tomcat ) - and that shouldn't
destroy the comments or the rest of the config structure.

I think that also maps well for ant ( at least when used 'embeded',
for standalone ant it's not an issue ).
> Perhaps studying these related problems will lead an ant developer to
> consider my proposal that much of the infrastructure and many of the
> infrastructure problems of ant could be eliminated by making ant into a
> bunch of mbeans running in an mbean server.

I don't have any doubt about this. Ant is already formed of tasks that
are perfectly fit for a model ( or dynamic ) MBean wrapper, same
for Target and Project. 

I don't think the MBeans should be very tight ( at least for now ), but
wrapping ant and using tasks/targets/projects via JMX is certainly
desirable ( and quite easy to do with the current ant and minimal changes ).
Right now I'm more interested on exposing ant internals via JNDI, 
since I thing the API is a bit more powerfull and easy to use and fits
better ( things like ant:env/properties/foo or ant:env/ref/bar ).


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

View raw message