On Friday 14 March 2008, Benson Margulies wrote: > So, > > Validation reduction is a worthwhile improvement, but there's still > quite a lot of time spent reading all our files. > > I can think of a few more or less wild and crazy alternatives. > > Sadly, Spring is very committed to the DOM. So my original idea of > StaX seems beyond a reasonable level of effort. Unless Xerces is such > a pig that we know a faster file-to-DOM path that starts with > WoodStox. Plugging such a thing into Spring wouldn't be especially > painful.
Unfortunately, woodstox doesn't support schema validation at all, so that is only a help in that case. (the 4.0 version of woodstox is supposedly going to add that) You can try it if you want. Create a stax XmlStreamReader, create a org.apache.cxf.staxutils.W3CDOMStreamWriter, then call StaxUtils.copy(in, out); (That said, I just noticed the W3CDOMStreamWriter constructor is creating a new DocumentBuilderFactory every time. That's not cheap either. It should be updated to call XmlUtils.newDocument()) > On the other hand, is there any way we can 'precompile' XML files into > some artifact that springs (ahem) into life as a DOM tree? I used to > work on an OODBMS. > > I wonder if reading PYX would be significantly faster than reading > XML. PYX seems to have largely evaporated. One thought I had was to create a shade transformer that would take all the cxf-* things in the bundle and merge them together into a single cxf-all.xml file that defines all the beans. When using the bundle, we could grab that instead of each individual xml file and thus create a single DOM. This is a non-trivial runtime change though as we'd need to get the URL's for all the META-INF/cxf/cxf-extension-*.xml stuff and somehow figure out which ones were already included in the bundle and pull them out of the list. For extensions that are NOT part of the bundle (like custom ones written outside CXF), they still need to be detected and loaded. It's just the internal ones that would need to be found. I suppose the transformer could output two files, the cxf-all.xml and a cxf-all-included.txt that just lists the files that were used to create cxf-all.xml. Or maybe a comment in the cxf-all.xml or something that could be examined post dom building. I'm honestly not sure how much of a benefit that would provide though. You may want to mock up a simple cxf-all and run that with your benchmark first to see if it would really help. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
