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]
