Choose a simple solution.
Have one log.debug statement in the end, and log all the parameters there: access token url, response, token gain value, and time. Also, since these statements provide information for every step, my hunch is that these info pieces are meant to troubleshoot. Use the log level as trace in that case.
TL:DR;
You ask,
"There are too much logging statements above. Is this normal?"
Answer is subjective. It is normal in the cases where it is meant to be an alternative to debugging using an IDE. We call it micro-logging. Good to troubleshoot, but hits performance in the prod environment because of too much I/O. Imagine this mirco-logged piece of code running in production with at least 500 threads accessing it per second. Also, the log will look like a nightmare.
You ask
" ...is there any technique to solve this problem"
It is not a problem. Code tweak is required. make sure log statements are less and exceptions are caught. In your code below, the url
are response
can possibly be null. Catch these exceptions or else there may be times when any amount of logging will end up being futile.
for exceptions which are caught, use a log.error in the catch block, with exception.getMessage()
.
String url = accessTokenUrl.getValue();
logger.debug("access token url : " + url);
String response = WechatHttpClient.post(url);
logger.debug("access token response : " + response);
Map<String, Object> map = JSONObject.parseObject(response);
accessToken = map.get("access_token").toString();
instant = Instant.now();
You ask,
..like AOP or design pattern ?
Again subjective, and varies according to applications. As a simple and naive example, you may want to use AOP for cases where multiple components access a common method doSomething(), each with a request with different data. You can you an AOP based solution to log the source of the request, and the non-sensitive request data in the log method. Call the log method "Before" the doSomething(). Start here to delve into the details