Validations in filter class
Instead of putting multiple if else blocks I thought it can be implemented as following.


Looks like the Strategy Pattern with polymorphic dispatch.
A sound plan!

Make fields final when possible

The private fields of Context can all be final.
It's good to make them final so you won't change them by accident.
final fields are easier to read, as you know they will only ever have the same value.

Avoid throwing Exception

IValidator.handleFailure is defined with throws Exception.
It's recommended to avoid using the generic Exception class,
it's better to use specific exceptions.
Code using this interface is forced to catch Exception,
which creates the risk that other exception types may be caught by mistake.

Implement just what you need

Do you need all the constructors in ValidatorException?
In the posted code, there isn't a single use case using of any of those.
I suggest to implement only the functionality you actually need,
and avoid to implement in advance something "you might need someday".

Conventions

In Java it's not a convention to prefix interface names with a capital I.
I suggest to rename IValidator to Validator.

The constant interface antipattern

You haven't shared the code of CWSConstants,
but it sounds like it might simply contain constants,
and your classes implement this interface only to have easy access to those constants.

This is considered a bad practice. Interfaces are intended for contracts of behaviors, using them for easy access of constants is an abuse of the language. The alternative is to put the constants in a class instead of an interface. You may use static imports to avoid polluting the code with the name of the class everywhere.