What we need is a generic delegating sax parser with dynamic element handlers passed in at runtime. Solves all your problems =)
The idea is that you add a layer on top of SAX that handles any XML event in a way that is optimised for handling in Java instead of for handling using xml or procedural work, without deciding for you what to do with it in terms of storage, character vs binary data, etc. I wrote some code for this in XCommander (which resides in avalon-apps) which I still plan to rip out some time when I have time, or plan to help someone do exactly that. I got the delegating sax parser from an old JavaWorld article, I think, and from some discussion with Pete (who was working on something similar within ant at that time, IIRC). I'm guessing similar code exists in Ant, Cocoon, Batik and other programs that do the low-level xml stuff (I think it is _not_ in Xerces or Xalan in this form, tho' - they're optimised for performance rather than extensibility in this particular way). the way I'd see it what you need here is - an excalibur subproject that provides this delegating sax parser - a rewrite of excalibur's SAXConfigurationBuilder to use this - an extension of SAXConfigurationBuilder for JMeter that handles JMeter's specific use case. I don't exactly understand that use case yet though, so I might be wrong. I should do some lookup in the archives about what I thought about all this :D Now to try and answer some specifics... > > First, I just extended DefaultConfigurationBuilder and > > SAXConfigurationHandler to handle my custom Configuration class > > (SampleResult). It was easy to do, but you might want to look into making > > SAXConfigurationHandler more supportive of extending. It's members are > > private, and there are no protected getXXX() methods to allow inheritors > > access to those members. So, in order to extend it, I simply copied and > > pasted all of it's code into my class, and then modified what I needed to > > (which was very little). But that's not ideal. >From what I gather the use case you have here either should be satisfied withing SAXConfigurationHandler, or should not be handled by a Configuration at all. That doesn't mean SAXConfigurationHandler shouldn't be more extensible though. > > What I changed - I simply added some code to instantiate the right kind of > > object in place of DefaultConfiguration (this is in the startElement > > method), based on what the tag name was. You might consider breaking that > > code out into a protected method that is easily overridden by extenders - > > that might handle a good percentage of customization needs. > > Ok. That seems reasonable. We may come up with something even better, > but this is good. Break out all those specifics into special protected methods, and you're halfway there. Now put those in classes, so customisation becomes easier (using composition). Encapsulate common functionality that all these methods require in common base classes. > > Second, I'm doing a lot of processing of SampleResults, and I'm a little > > worried about performance. I'm not one to care overly much about > > performance, but in the case of JMeter and issues during test runs, I have > > to be careful. I was wondering about easing the amount of processing that > > goes on by delaying the storing of data into the Configuration-style areas > > (ie attributes and values) until it's time for the SampleResult to be > > serialized to file. The way I see it, a Configuration does not need to be performant: you process them once, at startup, for a limited number of components (having many would mean having many configuration files, which is usually impractical). To me, it sounds like you're not really 'configuring' here, more feeding data. But I dunno much 'bout Jmeter, though. > Ok. Another option would be to save a reference to the file, and store > the binaries separately. dare I say 'jucky'? ;) I'm not very good at any kind of testing, especially not performance, but this sounds like something that makes it even more difficult to measure. > > Instead, data would be preliminarily stored in normal Java ways (ie as a > > byte[]), and I'd write a custom ConfigurationSerializer that would work with > > SampleResult to get everything squared away prior to serialization. > > > > Any thoughts on this? Maybe you can see a better approach? > > Maybe we can get a good idea going on the Avalon developer's list. I always use Context instead of Configuration when I have to handle binary data. I remember writing a hack once where a filename was passed using Configuration, which was requested from Context and only then loaded. This would mean an extension of Context behaviour, which would be easier as it is non-hierarchical. Once again, I don't think I really understand what you need here, so... grz, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
