issue-858 auditing timestamp supports custome date format #860
Conversation
|
What will happen if user accendtly provide invalid format? Can we stop the app from starting or fallback to some default format and signal the user that you entered invalid format that is why he are seeing fallback format? |
I can add a log if there's an invalid format, because in production, the format should be a tested one. What do you think? |
|
We cannot stop the server but should output an error status code designate for this error. It should be very easy to detect using the development and testing cycle and get it fixed. |
| verifyAuditInfo("timestamp", "2020-12-10T17:30:11.945-0500"); | ||
| } | ||
|
|
||
| /* @Test used for testing when doesn't specify timestampFormat |
There was a problem hiding this comment.
shall we delete this, if this test is not being used?
| @@ -358,6 +359,38 @@ public void testAuditWith401ServiceId() throws Exception { | |||
| verifyAuditInfo("serviceId", "com.networknt.petstore-1.0.0"); | |||
| } | |||
|
|
|||
| @Test | |||
| public void testAuditWith200TimestampFormatted() throws Exception { | |||
There was a problem hiding this comment.
Is it also possible to test the situation when adds the invalid format, with current solution, I would expect the app failing to start.
There was a problem hiding this comment.
Is it also possible to test the situation when adds the invalid format, with current solution, I would expect the app failing to start.
I will add a test for that, but the server won't stop because of the format error.
I'm trying to find a better way to set the format dynamically.
| @@ -20,6 +20,8 @@ auditOnError: false | |||
| # log level; by default set to info | |||
| logLevelIsError: false | |||
|
|
|||
| # the format for outputting the timestamp, if not specify, will use long value | |||
There was a problem hiding this comment.
lets also document here what would happen if the format that user entered is invalid.
BalloonWen
changed the title
* issue-858 - added timestampFormat in audit.yml, if timestampFormat is specified, then will use the format, otherwise will use long value * issue-858 - added status dependency - create status for invalid config value - now create formater at the server starting stage, if the provided format is invalid, it will log an error and use the default "long" style as the timestamp * issue-858 - improved comment Co-authored-by: Bolun Wen <bolun.wen@sunlife.com>
if the format of the timestamp is invalid, it will use a long value.