Add log guards to org.activiti.engine.impl.interceptor.LogInterceptor

isnt this duplicate of ACT-128 ?

No, I don't think so: it's solely for the logging within LogInterceptor class. Construction of the log statements is expensive in this case (concatenation of multiple strings):

log.fine("--- starting " + ClassNameUtil.getClassNameWithoutPackage(command) + " --------------------------------------------------------");
log.fine("--- " + ClassNameUtil.getClassNameWithoutPackage(command) + " finished --------------------------------------------------------");

The problem here is that constructing the log statements put additional load on garbage collection even if the messages are immediately discarded by the logging system due to fine logging level being disabled in a production application.

I suggest that you add log guardians (java.util.logging.Logger.isLoggable(Level)) to log statements in this class, since they are invoked for every single action, API call etc within Activiti; you also might want to use a StringBuilder or java.lang.String.format(String, Object...) to construct the log message so as to avoid unnecessary GC overhead.

This might be my personal preference, but you could potentially also consider removing additional dashes and white spaces from the log messages. (I understand that this adds some structure to the log messages, but at the same time, logging of additional ~300 characters might degrade overall application performance.)

The idea is that if you don't want logging, you do not configure the log interceptor. So that way, there is no concatenation of strings. If you think otherwise, reopen and discuss.

Reopened because it is not documented (is it even possible) to remove the log interceptor. So the solution should be either to make that possible through configuration and add it in the docs or otherwise, add if's around the log statements.

Setting interceptors based on the log configuration seems to be a good idea but has a downside: it doesn't allow you to change the configuration at runtime. With that approach, if you want to change logging level, you will need to edit the configuration, (presumably re-build) and re-deploy the application.

In contrast, with JUL you can change log level dynamically via JMX at runtime, without reconfiguring and re-deploying the application. Being able to set logging to debug at runtime might be very useful if you need to investigate a misbehaving production system. I suggest you keep the current setup where the interceptor is always added but add log guards so as to improve performance if debug logging level is disabled for the interceptor.

Good point, Peter. Thanks!

added a guard in the LogInterceptor