Few thought on our current logging enhancement. This was even written in issue #495. But seem to have closed it mistakenly without noticing my comment.
At present, we are using Java Util Logging(JUL). Following logging types are used.
We have used 2 styles of logging in the cotde. It is because first type(log with level supports passing third argument as throwable/object/object array etc. Whereas second type takes only string.
Type 1: logger.log(Level.FINE, “My string”);
Type 2: logger.info(“My string”);
Used concatenation(+), String.format and MessageFormat style as shown below. Both concatenation and String.format approaches constructs the message irrespective of logging level check. Where as MessageFormat style doesn't construct log message(i.e., toString of object not called if log is disabled. But new Object[] array needs to be created to pass arguments even if log is disabled.
Snippets from current code:
Type 1[Concatenation style]:
logger.log(Level.WARNING, "Added " + oid.getID() + " as unknown type.");
Type 2[Concatenation style]:
String exceptionMsg = "Initialization failed at copyKernelObject for KernelObject(" + koid.getID() + "). ";
logger.severe(exceptionMsg);
Type 3[String Format style]:
String msg = String.format("Failed to copy object to server oid:%d, target host:%s", oid.getID(), host.getHostName());
logger.severe(msg);
Type 4[MessageFormat style]:
logger.log(Level.FINE, "response for request {0}: {1}", new Object[] {request, response});
But requires new Object[] array if arguments are more than 1. And this object array is created even if log is disabled.
Should we switch from java.util.logging to Simple Logging Facade for Java(SLF4J) so that, it allows the end user to plug in the desired logging framework((i.e., logback/log4j2/JUL etc ) at deployment time ? Provides better parameterized logging performance for disabled log statements. And, Provides support for binding to various log frameworks and allows for better customization. In my opinion, SLF4J seem to be good option.
Few thought on our current logging enhancement. This was even written in issue #495. But seem to have closed it mistakenly without noticing my comment.
At present, we are using Java Util Logging(JUL). Following logging types are used.
We have used 2 styles of logging in the cotde. It is because first type(log with level supports passing third argument as throwable/object/object array etc. Whereas second type takes only string. Type 1: logger.log(Level.FINE, “My string”); Type 2: logger.info(“My string”);
Used concatenation(+), String.format and MessageFormat style as shown below. Both concatenation and String.format approaches constructs the message irrespective of logging level check. Where as MessageFormat style doesn't construct log message(i.e., toString of object not called if log is disabled. But new Object[] array needs to be created to pass arguments even if log is disabled. Snippets from current code: Type 1[Concatenation style]: logger.log(Level.WARNING, "Added " + oid.getID() + " as unknown type."); Type 2[Concatenation style]: String exceptionMsg = "Initialization failed at copyKernelObject for KernelObject(" + koid.getID() + "). "; logger.severe(exceptionMsg); Type 3[String Format style]: String msg = String.format("Failed to copy object to server oid:%d, target host:%s", oid.getID(), host.getHostName()); logger.severe(msg); Type 4[MessageFormat style]: logger.log(Level.FINE, "response for request {0}: {1}", new Object[] {request, response}); But requires new Object[] array if arguments are more than 1. And this object array is created even if log is disabled.
Should we switch from java.util.logging to Simple Logging Facade for Java(SLF4J) so that, it allows the end user to plug in the desired logging framework((i.e., logback/log4j2/JUL etc ) at deployment time ? Provides better parameterized logging performance for disabled log statements. And, Provides support for binding to various log frameworks and allows for better customization. In my opinion, SLF4J seem to be good option.
https://www.slf4j.org/