OK, I'll review the logs and remove those ones that certainly unnecessary. Then we'll see what are the remaining ones and what to do with them.
Thanks, Mikhail. On 1/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > That's true - but then it should be turned on when you are looking for > said bug. If things are running fine, keep the logging off. > > geir > > Stepan Mishura wrote: > > I'd like to add that logging may help when you are not able to reproduce a > > bug. > > > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > > > On 1/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > >> On 1/24/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >>> Mikhail Loenko wrote: > >>>> Hello > >>>> > >>>> We have figured out that one of approcahes that was earlier dicussed > >> and that > >>>> I originally opposed would work for us. > >>>> > >>>> That is: get PerformanceTest class out of there and replace log() with > >> calls > >>>> to java.util.logging.Logger. > >>>> > >>>> Please let me know what you think. > >>> What are you logging? > >> Normally any information that would be useful to easily detect > >> the reason of failure. A good test explains why it failed, the best test > >> submits a bug report and provides a patch, the worst test > >> just complains that it failed. > >> > >> I would not wish to debug just to figure out that the reason of failures > >> is > >> that I've forgot to include something to classpath or there is another > >> config problem > >> > >>> Nobody is going to search log files looking for success/failure > >> messages. > >> > >> Agreed > >> > >>> If the test passes, then all is fine; if it does not pass then it should > >>> inform the framework (i.e. a failing assertion or an explicit call to > >>> fail()). At that point JUnit will give you a cause of failure, and if > >> fail() is not always convinient, for example, how would you print > >> stack trace to fail()? Meanwhile stacktrace is most often enough > >> to find what the problems are and sort them out. > >> > >> Thanks, > >> Mikhail > >> > >>> that is not enough you debug it with a debugger not println's. > >>> > >>> Regards, > >>> Tim > >>> > >>> -- > >>> > >>> Tim Ellison ([EMAIL PROTECTED]) > >>> IBM Java technology centre, UK. > >>> > > > > > > > > -- > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > >
