Details
-
Bug
-
Resolution: Unresolved
-
Trivial
-
1.10
-
None
-
None
-
Bit Sprint 1, Bit Sprint 2
-
Go to e.g. http://int-bitmag-02.kb.dk:8080/bitrepository-webclient/audit-trail-service.html and then ssh to bm_webservice@int-bitmag-02.kb.dk
and look at the audit-trail-service logs.You will then see this a lot:
"2022-06-21 13:29:27.861 INFO o.b.common.utils.CalendarUtils - Using timezone:..."
"2022-06-21 13:29:32.881 INFO o.b.common.utils.CalendarUtils - Using timezone:..."Go to e.g. http://int-bitmag-02.kb.dk:8080/bitrepository-webclient/audit-trail-service.html and then ssh to bm_webservice@int-bitmag-02.kb.dk and look at the audit-trail-service logs. You will then see this a lot: "2022-06-21 13:29:27.861 INFO o.b.common.utils.CalendarUtils - Using timezone:..." "2022-06-21 13:29:32.881 INFO o.b.common.utils.CalendarUtils - Using timezone:..."
Description
The Audit Trail Service's underlying REST-application "RestAuditTrailService" seems to be request-scoped meaning that the bean is initialized on every request sent to e.g. http://<hostname>/bitrepository-audit-trail-service/audittrails/AuditTrailService/collectionSchedule/.
As this request is sent on a regular interval (seems 5 sec is default) when the audit trail GUI page is active, RestAuditTrailService is instantiated very often, which in turn instantiates CalendarUtils that logs its used timezone on INFO very often.
The easy solution is to just move the log to a lower level like TRACE, but with my limited knowledge on JAX-RS/-WS/-whatever and the surrounding implications I believe nothing would be hindering this bean from being something like session-scoped instead.
I made a quick attempt at fixing this, but it seems it takes more than just writing @SessionScoped on the bean. I know too little about this.