Improve logging

[jrambla]

The current logging doesn't allow for a complete and useful debug of situations.
The Beacon Production Implementation logging could be used as a model for what we would like to have, although it doesn't include (obviously) detalls on the beacon responses or lack of.
Happy to discuss the details with you.

[redmitry]

The current logging doesn't allow for a complete and useful debug of situations.

Currently there are several levels of logging:

• "NONE" : No logging at all.
• "METADATA" : Only backed beacons' metadata is logged (good for debugging).
• "REQUESTS" : Beacon Network Request queries are logged. It also logs response codes (but not the data).
• "RESPONSES" : Logs all Requests with Responses as well as possible error messages.
• "ALL" : Maximum logging level. Currently same as "RESPONSES"

The log is stored in PostgreSQL "log" (although may be easily adopted for other SQL).

• "id": big int - log record identifier
• "xid": uuid - operation identifier - e.g. user query for individuals so all calls / responses for the operation have same operation identifier
• "timestamp": timestamp - time of the operation. note that we can easily calculate request / response times within the same "xid"
• "type": smallint - enum [METADATA, QUERY]
  0 is the operations initiated by the BN (interaction with beacons like asking for metadata),
  1 is the users' queries
• "method": smallint - enum [GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE] - HTTP METHOD
• "url": character varying (string) - the HTTP request URL
• "request": text - the request body (for POST)
• "response": text - query response
• "code" integer - HTTP Response code (e.g. 200)
• "message" character varying (string) - additional server comment if any

Beacon Network also provides some warnings and errors to the WildFly log.

Cheers,

D.