What is the alternative for LOGGER.entering() and LOGGER.exiting() from Java logger to log4j2 using slf4j

[mehulparmariitr]

I am migrating code base from simple java logger to log4j2 using sl4j because of having issue while writing asynchronously to a single log file in multiple threads. I noticed entry and exit methods are not available in sl4j interface. what is the best to achieve entry and exit to print class name, method name and parameters which can be object.

[ppkarwasz]

The equivalents of JUL's Logger#entering(String, String, Object[]) and Logger#exiting(String, String, Object) are:

• Logger#traceEntry,
• Logger#traceExit.

Basically these allow you to replace:

private static final java.util.logging.Logger logger = ...

public String computeFoo(String param1, int param2) {
    logger.entering("org.example.MyClass", "computeFoo", new Object[] {param1, param2});
    // do something

    //
   logger.exiting("org.example.MyClass", "computeFoo", result);
   return result;

with:

private static final org.apache.logging.log4j.Logger logger = ...

public String computeFoo(String param1, int param2) {
    logger.traceEntry(null, new Object[] {param1, param2});
    // or just
    logger.traceEntry(null, param1, param2);
    // do something

    //
    return logger.traceExit(result);

As you can see the location information is removed, because most modern logging backends can compute it on the fly. E.g. with Log4j Core (the reference implementation of Log4j API) you can use:

<PatternLayout pattern="...%C#%M %m%n"/>

Normally runtime location information is expensive, but you can pre-compute it as compiletime using the Log4j Transform Plugin.

Remark: This solution requires using Log4j API instead of SLF4J. The default SLF4J Logger has no entry/exit methods. If you really want to use SLF4J there is a slf4j-ext artifact with an XLogger class. If I am not mistaken the entry/exit methods were introduced in XLogger class by @rgoers, before he decided to start Log4j 2.x.

[ppkarwasz]

Personally I am not a big fan of the traceEntry/traceExit methods.

I believe that this functionality should be provided by aspect-oriented programming. We might for example enhance the aforementioned Log4j Transform Plugin to add entry/exit log statements to a configurable set of methods. Would you mind adding a feature request to the logging-log4j-transform repository? Please explain there what kind of methods you want to decorate with entry/exit log statements.

[mehulparmariitr]

I am building a customLogger on top of log4j2. How will this custom logger know the name of method automatically to pass to Logger#traceEntry?

[ppkarwasz]

It won't if you use Logger#traceEntry.

Classes that wrap a Logger instance should only use the methods in Logger and ExtendedLogger that have a parameter called fqcn. This parameter must contain the fully qualified class name of your logger class and allows Log4j API implementations to find the location information of the caller (module name, class name, method name, source file name, line number, etc.)

The ExtendedLogger interface is specifically provided for integrators and it is hidden from normal users. However every Logger implements ExtendedLogger (you can just cast it).

BTW: I just opened an issue on OpenRewrite (openrewrite/rewrite-logging-frameworks#132) to add a JUL to Log4j API conversion recipe. IMHO this might be a faster and more stable solution to your problem.

[ppkarwasz]

Check my OpenRewrite PR for a basic JUL to Log4j API conversion: openrewrite/rewrite-logging-frameworks#133

[ppkarwasz]

@mehulparmariitr,

Tim already accepted my org.openrewrite.java.logging.log4j.JulToLog4j recipe. Can you check the OpenRewrite snapshot version to see if it helps in your migration task?
If you prefer a stable release, rewrite-logging-frameworks have a release every 2 weeks.