Would this change the log file format as well? There may well be utilities that depend on the current format (e.g. the Ant utility in /extras) Also, having larger log files would definitely be a problem.
We don't use large test plans (yet ...) so an increase in the size of these is not a big deal. If they are easier to read that would be useful, as it might avoid having to launch JMeter just to find out what the plan is doing.. Can you perhaps post some samples to show what they look like? (perhaps on the Wiki, to save bandwidth here). Also, what about UTF characters? Are these handled OK?. S ----- Original Message ----- From: "Michael Stover" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 18, 2004 12:54 AM Subject: using xstream to save .jmx files I recently experimented with replacing JMeter save/load code with xstream's java xml serialization code. I'm wondering how people feel about it. The advantage is the code is 100% simpler. 5 lines of code replace the hundreds currently living in SaveService. The disadvantage is that, without customization, the xstream version of the files are 3-4x larger. Speed, however, appears unchanged. On my local system, JMeter can load both previous versions and xstream versions, so that's not an issue. Also, I would include file versioning with it so that a test plan file would include the jmeter version that made it. This would help in the future with backwards compatibility. I personally like it, but then, a file going from 100k to 400k is no big deal to me - I don't save 10000 objects in my test plans (100 and 400 are the relative sizes of the guitest.jmx file) Any opinions? -- Michael Stover <[EMAIL PROTECTED]> Apache Software Foundation --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
