Flux 4.2 includes a new web user interface for monitoring jobs from a web browser. It also includes a JSP tag library, which allows web designers to create web pages that interact with Flux without writing Java code.

Flux 4.2 also includes full-blown support for logging and and an audit trail. Flux logs a wide variety of log messages at different levels of detail. Supported logging tools include Log4j, the JDK 1.4+ logger, and Jakarta Commons logging.

The Flux audit trail logs audit messages at well-defined points in the job scheduler. These audit messages can be redirected to a file, database, etc in order to monitor job scheduler activity.

Finally, Flux 4.2 includes enhanced timing functionality, the ability to create job listeners, support for WebSphere 5.0 and more SQL Server JDBC drivers, and other useful features.

Jakarta Commons Logging is an API to have loose coupling with the logging library.
You should use Jakarta Commons Logging to enable yours users to choose between the JDK1.4 logger or the log4J, ... or even another logger (for example the SimpleLogger provided with the Jakarta Commons Logging )

This is a typical senario when many components in j2ee system using Jdk logging or Log4J. You may have unwanted consequence on other components when you change logging configuration on one component. See "JDK leaves a back door widely open for un-synchronized control of the system" from
Are Jdk Logging Or Log4J Ready For J2ee?

Guillaume brings up a good point. I've been asked before why Flux didn't just use Jakarta Commons logging and be done with it. The thing is, Flux is a software component (class library). As such, Flux is embedded in other applications that may already have a logging mechanism in place.

If Flux forced the user to use Jakarta Commons logging, that would force Log4j users to create a Jakarta Commons logging configuration file or setup Jakarta Commons logging system properties. But if the end user is simply using Log4j, he or she won't want to mess with Commons logging. She'll just want to use the Log4j she's always used.

If a Flux user just uses Log4j, we don't want to force them to deal with Commons logging. So that's why Flux supports Log4j, the JDK logger, *and* Commons logging, so that there is a clean transition from Flux logging to the enveloping application's logging.

(You can also use a simple built-in logger or disable logging altogether.)

If you tell Flux to use Log4j, you give Flux the Log4j logger name. Flux then just looks it up and uses it. There's no need to configure a separate logger. To avoid multi-thread issues when accessing a logger, Flux uses a documented synchronization policy of synchroning on the actual logger object before using it, since it's not guaranteed that the various logger objects are thread-safe.

To use Wei's SuperLogging system, you could tell Flux to use Commons logging and then write a Commons adapter for SuperLogging. That would force Flux to log to Commons logging, which would, in turn, log to SuperLogging.

I think the takeaway point here is that when you have a software component that is going to be plugged into somebody else's application, you want to do what you can to accommodate that application's existing architecture. If you can help it, you don't want to force changes upon that architecture.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.