...
Once upon a time, like every other Java project on the planet, uPortal invented and maintained its own LogService. It was a static singleton that knew how to write to a log file.
In which uPortal's legacy LogService evolution is traced to the presentIt was enhanced to be implemented using log4j and to support log levels. This allowed a single universal logging level to be configured for the uPortal instance, and this would control globally how much logging was recorded.
Log4j operates under a metaphor of named loggers, with loggers by convention taking names associated with the fully qualified of the class name of the class doing the logging. This enables advanced configurations in which different components log at different levels. While I am developing the web proxy channel, I might configure logging to include great detail from the web proxy channel while continuing to only log the most important messages from the rest of the framework.
Accessing log4j via the uPortal static LogService prevents taking advantage of these capabilities. All logging via the LogService appears to "come from" the LogService implementation itself.
Fortunately, Jakarta Commons has implemented a thin wrapper Logging API that fulfills many of the requirements that uPortal LogService tried to fulfill. Commons Logging supports log4j as well as other backing logger implementations and is commonly used by uPortal dependencies as well as uPortal itself so skills configuring and using Commons Logging apply universally.
Some logging recipes and motivating examples
...