A major goal is to maximize the fault coverage while characterizing software failures. Currently, the fault injection scheme emulates common programming mistakes. Spsecifically, we inject three variants of null-call when bar() returns the call from foo(). Null-Return, where a null is returned on a call to a business method, Null-Object-Return where a null is cast into the return type and returned, No-Op, where an empty object of required return type is instantiated and returned. Further, we also inject unchecked exceptions, i.e., ArithmeticException (due to a divide by zero), ArrayIndexOutOfBoundsException (due to out of bound array access) and ClassCastException (due to bad casting).

Another important goal is transparent injection and detection of failures. We achieve this by using the interceptor and filter technology that avoids polluting the default source code of the web application. A standalone interceptor/filter can be configured to intercept calls between application components.

It is important to be able to design rules that detect failures. We learn the rule parameters, e.g., call-length by running the workload in a training run that has injection mechanism turned off. To learn rule paramaters in training mode, we follow a simple approach and determine frequency distribution of a discriminant feature (call-length).