great, thanks! peter
On 5/14/05, sebb <[EMAIL PROTECTED]> wrote: > I've added a new property: > > jmeter.save.saveservice.response_data.on_error > > when true, responseData is saved for samples that are not successful. > > So non-gui (e.g. Ant JMeter) runs can now easily save response data > just for samples that fail. > > Also fixed functionalMode so it works again. > > S. > > On 5/9/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > Making the -l listener super configurable would not be high on my list > > of priorities - after all, all the listeners you set up in your test > > still work in non-gui mode, so if you need something more complex, one > > can include it in the test plan. The command line listener is just > > there for convenience. > > > > As for all the checkboxes, I'm not sure I follow where they're all > > going. > > > > -Mike > > > > On Mon, 2005-05-09 at 18:03 +0100, sebb wrote: > > > Sorry, I was unclear - I think the "Log Errors" checkbox is still > > > needed on the listener too. > > > > > > I don't propose changing the Listener GUI interface to move the "Log > > > Errors" checkbox, apart from adding a "log result data if error" > > > checkbox to the config element. > > > > > > == > > > > > > I'm not keen on having to edit the JMX file - in fact, as far as I can > > > see it won't work, because the non-GUI Listener is created at > > > run-time. > > > > > > So I am proposing adding a property that can be used by the non-GUI > > > Listener to determine if it should log result data for errors only. > > > This would correspond with the new config checkbox. > > > > > > == > > > > > > I'm not sure if any other result fields need to be independently > > > configurable for successful/unsuccessful samples. > > > > > > This could make the config GUI very large, unless there were two per > > > listener perhaps? > > > > > > Not tested this, but I think one can have two Listeners writing to the > > > same file, one with "Log errors only" selected, and each can have > > > different options. > > > > > > [This does not work for the non-GUI listener, however.] > > > > > > S. > > > On 5/9/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > I still see "Log Errors" on the listener being useful too. As for non- > > > > gui running, I think the new jmx file format makes editing listener > > > > properties easy enough to be something to consider. > > > > > > > > -Mike > > > > > > > > On Mon, 2005-05-09 at 16:07 +0100, sebb wrote: > > > > > I did consider using the Listener Config. > > > > > > > > > > However that gives a problem for non-GUI runs, as there is no way to > > > > > configure the automatic listener (apart from via properties). > > > > > > > > > > I guess there's no real need for a "Log Errors" checkbox to be added > > > > > to the Test Plan - it could just be done via a property, which I was > > > > > going to add anyway. > > > > > Indeed, do we need the Functional test checkbox? > > > > > > > > > > I think the "Log Errors Only" checkbox is better as a separate item - > > > > > it defines when to log, the config defines what. Besides, moving it > > > > > might invalidate a lot of test plans. However, result data should only > > > > > be logged if the config says to do so. > > > > > > > > > > S. > > > > > On 5/9/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > > > That all sounds reasonable. But, what about making the listener > > > > > > config > > > > > > do it all - ie, let users indicate what to save normally, what to > > > > > > save > > > > > > on errors etc. I think that makes more sense than the ad-hoc > > > > > > checkbox > > > > > > on the TestPlan object approach. > > > > > > > > > > > > -Mike > > > > > > > > > > > > On Sun, 2005-05-08 at 11:53 +0100, sebb wrote: > > > > > > > Functional mode does not work currently in 2.1. > > > > > > > > > > > > > > Whilst looking into this, I noticed that "Log Errors only" does > > > > > > > more > > > > > > > in 2.0 than just prevent successful results from being sent to the > > > > > > > visualizers - it also behaves like Functional Test mode for failed > > > > > > > results, in that the result Data is written to the test log. > > > > > > > > > > > > > > In 2.1 at present, "Log Errors only" behaves as I expected, i.e. > > > > > > > it > > > > > > > suppresses successful results from appearing in the Listener (and > > > > > > > its > > > > > > > log file) and it does not affect the data written to the log file. > > > > > > > > > > > > > > Seems to me it would be useful to extend the Test Plan GUI to add > > > > > > > an > > > > > > > option to log Result Data for errors only. This would be useful > > > > > > > for > > > > > > > checking why an assertion failed. > > > > > > > It would also be useful to add an equivalent property so the mode > > > > > > > could be set from the command line. > > > > > > > > > > > > > > == > > > > > > > > > > > > > > I'd also like to suggest a change in the way Functional mode is > > > > > > > implemented: > > > > > > > > > > > > > > At the moment, Functional Test mode is stored as a property by > > > > > > > TestPlan, and ResultCollector then stores it as a static variable. > > > > > > > > > > > > > > There will only ever be one Test Plan class in a Test Plan, so it > > > > > > > would be easy to add static methods to it to return the current > > > > > > > settings for Functional Test Mode (and my proposed Error Result > > > > > > > Data > > > > > > > mode). This would make it easier to check (at present the setting > > > > > > > is > > > > > > > copied to the ResultCollector class by scanning the classes.) > > > > > > > > > > > > > > [The TestPlan.FUNCTIONAL_MODE property would need to be kept so > > > > > > > as to > > > > > > > be saved in JMX files] > > > > > > > > > > > > > > == > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > S. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
