We could get another very visible speedup out of the time it takes to initialize the bus with Spring. Since the predominant cost is still XML reading, even with WoodStox, any reduction in this process can be very visible. I posted the raw comparison of WoodStox and FI yesterday.
Before I go here (and, arguably, I should hold this horse until after 2.1), I want to make sure that folks appreciate the implications. It would work as follows, I think. 1) we'd add an mvn mojo to 'compile' XML files to FI blobs. 2) I've already given us a customized subclass of Spring's XML reading class. I propose to make it work as follows: when asked to read an XML file, it will look to see if there is a file with '.xml' replaced by '.fixml' in the same place. If it's there, it will load it preferentially. This has the potential to make life a bit interesting in eclipse. Developers modifying the .xml files will need to run mvn -Pfastinstall to recompile in order to see their changes, unless I include (e.g.) a system property to turn off this mechanism. I confess that I don't have much enthusiasm for trying to make eclipse keep up. Also note that none of this is any help to users who make their own application context and start including our files unless we document for them how to use our reader in preference to the stock Spring reader. We might feel that 'ControlledValidationXmlWhateverICalledIt' is not the right class name if we are going to advertise this. *That* might be a change that wants to be made for 2.1. Anyway, this is potentially disruptive/strange enough that I have no interest in tacking it without some evidence of consensus or disinterest.
