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

I've seen and tried few systems - some worse than others. 

Using JMX to intercept the config changes was one of the solutions
I tried - but as I said, I don't think it's the right solution.
JMX is far from a good API for data persistence ( JNDI has
defects, but it was at least designed for directories and data).
And JMX is hard to make work in a 'passive' mode ( i.e. without
runtime objects ).

BTW, I think this discussion would be better on tomcat-dev than ant.

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

Jboss deployment is not bad, but I don't think it's perfect either. 
About XSL transformations and XML config files - I would rather see
the config get away from beeing tied to XML. ( and I would like
 to see ant working without having to have an xml file around ).

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

I actually want to change the original source when making a change.
( and by source I am also thinking LDAP directory or registry )

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

That's one of the big problems. Quite easy to work around even with 
JMX by using 2 layers. In ant you have the 
UnknownElement/RuntimeConfigurable, with JMX you can have the model mbean
wrapper - and those can store _only_ original config data and what 
gets changed. 

This way you don't ask the bean directly for config, but you ask the
mbean for what it stored. The system works pretty well - and you can
even preserve ${properties}.

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

As I said, I have no problem with overriding or changing the original
source. That makes a lot of sense if you consider non-file sources
like directories. 

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

There are 2 different APIs with different goals. JMX is great when you
change runtime objects. JNDI is great when you work with a ( possibly
multi-source/federated ) hierarchical data storage. 

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

I don't know about the whole community, but at least I am very interested
in 'embeded ant' and using it via APIs. And JMX is a perfect fit 
for the ant internal model. 

I don't think we can expect ant to depend on jmx, but to wrap it
would be quite easy. I'm trying to extend the TaskAdapter to be 
able to wrap MBeans, so both ways should work ( ant tasks used as
mbeans, and mbeans used inside ant as tasks ).

( I'm not sugesting any of this will get into 'main' ant anytime
soon - just that it will be possible using hooks )


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

View raw message