CPS Logging Guidelines

It is up to the consumer of the java API if they want to log the exception or not. 

In the REST API when we catch an exception we should log it as we lose a lot of information when we convert it into a HTTP response code.

For business exceptions we will use error level but we will add configuration so that it is not written to the console by default.

You should log the original exception if it provides more information. 

Exception should be logged as close to the source as possible.

For business exceptions we will use error level but we will add configuration so that it is not written to the console by default.

Check logging level when constructing strings i.e. using more than one static string.

One or more key business functionalities are not working and the whole system doesn’t fulfill the business functionalities.

One or more functionalities are not working, preventing some functionalities from working correctly.

Unexpected behavior happened inside the application, but it is continuing its work and the key business features are operating as expected.

An event happened, the event is purely informative and can be ignored during normal operations.

A log level used for events considered to be useful during software debugging when more granular information is needed.

A log level describing events showing step by step execution of your code that can be ignored during the standard operation, but may be useful during extended debugging sessions.

1

 If the user tries to add an anchor with no dataspace we will log "Dataspace does not exist".

Error

This will be logged in the place it is handled. 

2

Where exactly to log error, at source or a common central place?

1. Prevent same error being logged may times (some duplication might be unavoidable though)

2. Consider that REST layer is optional (so that is why the current commit is not a good solution for centralized logging)

Error

This will be logged in the place it is handled.