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]
