Rework on the logging

[peidong-hu]

Logging needs to be reworked to handle the errors, debug info. etc correctly by aop.

Logback logger is printing logs based on the logger constructor parameter.

[peidong-hu]

This issue is related to exception throwable handling. We will need to review all these aspects of ate to rework on them.

[peidong-hu]

1) current design,

a) 3 exceptions b) errormessage and error code is centralized in one class c) AOP handles those 3 exceptions d) logs only supported for those 3 exceptions e) some steps are logged, some not f) elementfind and elementaction not logged g) several issues can be consolidated into one about exception handling, logging/reporting h) debug, info, error and other level logging information is not differentiated

2) what we need

a) extendable exceptions/throwables and exceptions/throwables needs to add flags to indicate if we will fail the test step or test case. b) extendable errormessage and errorcode design c) aop handles more exceptions and errorcode d) logs/reports handle more exceptions or throwable e) log all steps f) log all elementfind and elementaction g) log the screenshot on failure or exceptions not causing failure h) accommodate different levels of logback logging mechanism

[peidong-hu]

1) page object/data/io layer (Model layer) doesn't know if the throwable could fail the test or not 2) step/case/suite/project/asserter (Controler layer) is in charge of the judgement of throwable fatality for test case 3) result/logger/reporter is where the throwables are handled in addtional of 2) by controllers. resultmaker/logger/reporter are considered as controller too (non business logic controller) 4) xmlschema is View layer knows if the throwable could fail the test or not. this layer is in charge of user input xml validation and throwables should be handled properly for different purpose, for example, stop test case or continue and print warning messages in report/application/system log files

a) throwable will be converted to problem in 2) 3) and 4), a new interface ProblemCreator will be created, throwables implemented this interface will be handled by ate application and system loggers. Test case/test project/test step information + exception information will be included into the problem object. the flag 'concecoince' of probem and logLevel as construction parameter needs to be judged to fail or not fail the step/case b) ate throwable needs to provide problem wrapper to be invoked by the problem factory to return problem for problem handler.

c) for the non throwable logging/reporting, three loggable annotationn need to be added for step, objectfinder and objectaction , a capability interface desgin should be used for this type of logging reporting handler for coding extendibility, refer to the elementfind and elementaction for how to design this. These information will be logged as info level logback application and system level log. Report make will generate report based here too.

Design suggestion //1) an interface called throwablehandler or AOP point cut flag should be created to add throwable handling capabity to any class, this interface will provide the following contract // a) ate throwables handled // b) what type of handlers should be triggered.

i) for problems handlers, we already have the handlers in org.bigtester.ate.systemlogger.problemhandler (might need to be renamed.) User could register own handler. The Reflection class needed to do this. the xsd name space handler is an example for how to implement this.

ii) for non-problem logging/report, logback levels will all be logged as INFO logLevel

[peidong-hu]

Problem will be in charge of test case steps routing and test case failure status.

Currently BaseATECaseExecE is in charge of steps exceptional routing which is causing error if the throwable is not subclass of it, for example, testdata exceptions.

Problem will take over this responsibility. This code fragment demos this existing bug. We will modify this to use Problem to take care of it.

[peidong-hu]

application logging including error, warning and info levels done. (application log only handle these 3 levels.) this log will be used by script users to tackle xml script issues.

this is a milestone of phase1

debug and trace log will be logged in systemLog which haven't been coded yet.

[peidong-hu]

repeat needs to be better tuned.