registry-sync: use consistent log messages across protocols
11255
Reporter: kbraak
Assignee: fmendez
Type: Improvement
Summary: registry-sync: use consistent log messages across protocols
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2012-05-29 14:29:34.104
Updated: 2013-12-16 17:51:03.933
Resolved: 2012-06-13 17:25:43.885
TimeEstimate: 0
TimeSpent: 7200
Description: Depending on the Protocol, the log messages can be written differently for the same task, like updating dataset.
For example, for TAPIR, the log message for the update of a dataset is:
Dataset f0f8e840-1df9-11de-be11-b8a03c50a862 synchronized, status: OK, statusCode: null, message: null
for BIOCASE, it's: Dataset updated/synchronized cf8bdaa2-9dc4-11e1-9773-0024e8565763
Since the HIT operator isn't interested in stuff like "status: OK, statusCode: null, message: null", the BioCASE log message is closer to what the HIT operator would find nice to read.]]>
Author: kbraak@gbif.org
Created: 2012-05-29 14:43:38.261
Updated: 2012-05-29 14:43:38.261
messages like:
null null synchronized, status: ERROR, statusCode: null, message: null
Need to be more descriptive or not appear
(for reference, occurred during sync of tech inst: 50247346-990a-11e1-aa26-344ee9a6839c)
Author: kbraak@gbif.org
Created: 2012-06-11 17:58:01.702
Updated: 2012-06-11 17:58:01.702
Going to reopen. Seeing messages that could be elaborated, such as Response cannot be parsed. Screenshot attached. Information such as the type of response, any error (fx non-utf8 character encountered), service/dataset would be helpful.
The technical installation is a TAPIR one: 16a606ba-b3a0-11e1-9773-0024e8565763
Author: fmendez@gbif.org
Comment: More detail about each error is recorded in info_as_json column, that information is not displayed in the UI, the logging messages have been improved, but probably a better solution could be show to the user the content of info_as_json column when it is not empty.
Created: 2012-06-12 10:28:00.03
Updated: 2012-06-12 10:28:00.03
Author: kbraak@gbif.org
Created: 2012-06-13 14:47:42.997
Updated: 2012-06-13 14:47:42.997
I will try to look into why the info_as_json cannot be read, and the HIT is throwing
com.googlecode.jsonplugin.JSONException: Input string is not well formed JSON (invalid char o)
at com.googlecode.jsonplugin.JSONReader.buildInvalidInputException(JSONReader.java:155)
at com.googlecode.jsonplugin.JSONReader.read(JSONReader.java:119)
at com.googlecode.jsonplugin.JSONReader.read(JSONReader.java:72)
at com.googlecode.jsonplugin.JSONUtil.deserialize(JSONUtil.java:138)
at org.gbif.harvest.webapp.action.model.LogEventDTOFactory.deserialize(LogEventDTOFactory.java:124)
at org.gbif.harvest.webapp.action.model.LogEventDTOFactory.buildFrom(LogEventDTOFactory.java:105)
at org.gbif.harvest.webapp.action.LogEventAction.tail(LogEventAction.java:180)
Author: kbraak@gbif.org
Created: 2012-06-13 15:31:05.385
Updated: 2012-06-13 15:31:05.385
As discussed, the exception is being thrown, because the log_event.info_as_json column has invalid json. The relates to the registry-sync DataBaseLogAppender.
In the old HIT's I18nDatabaseAppender, there is a method that decomposes an exception into JSON. Please refer to protected void append(LoggingEvent event) for the exact code.
Author: fmendez@gbif.org
Comment: The DataBaseLogAppender is now converting the Throwable instances into JSON string.
Created: 2012-06-13 17:25:43.918
Updated: 2012-06-13 17:25:43.918
