ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Project.toXML() ?
Date Mon, 14 Oct 2002 02:37:29 GMT
On 2002.10.13 20:53:36 -0400 Costin Manolache wrote:
> 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 :-) 

Well, did you experience the incredible confusion of this system?
> 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 ).

JMX persistence is not a way to instantiate new mbeans.  You still need a
"deployment" step.  I'm fairly happy with the current jboss mbean
deployment system, based on multiple xml files with the possibility of xsl
transformations.  I find this orders of magnitudes more powerful than
anything I have seen done with jndi (admittedly, not a lot).

A couple of the problems with writing out an imitation of an original xml
deployment configuration as a means of persistence:

-You don't want to overwrite the original source file -- it's a source
file.  Therefore you have to write the copy somewhere else.  Now you have 2
versions of the file.  When restarting, how do you decide which copy gets
priority if they disagree?

-Most mbeans have a lot of attributes that come with default values which
may not be specified explicitly in the deployment descriptor.  Unless they
are model mbeans with carefully configured default values, you can't really
detect that the values are defaults, so you have to write all the attribute
values to storage.  This can result in unreadably longer files.

The solution I'm working towards for jboss when using the timestamp based
auto-redeploy is to model the originally deployed xml deployment
descriptors as mbeans, including something like a modification timestamp. 
These mbeans and the timestamp will be persisted through jmx.  When the
server shuts down and wakes up again it can tell by comparing timestamps
from the mbean and the actual file if the descriptor has changed, and
redeploy the mbeans from the file if necessary.

> 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 ).

I _really_ don't understand this.  Maybe I am biased from having worked
with the jboss xml based mbean deployment descriptors for so long, but I
find both them and working directly with mbean attributes much more
powerful than jndi.  

Anyway, I am very glad to see interest in jmx in the ant community.

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

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

View raw message