Some records about log4j. jar and commons-logging.jar

Recently, a project is released in WebSphere, which often causes problems that cannot be generated by logs. I searched the internet for some information about log4j and commons-logging. Now I have recorded it below:

First, let's talk about the origins of these two packages. log4j is a common package that Apache is used to record logs in projects, why does Apache need a commons-logging package? I think it's a lot more than Apache, because JDK later provides a log (java.util.logging.Logger), So Apache uses commons-logging to encapsulate it and provides an implementation (Org. Apache. commons. Logging. impl. jdk14logge ).

In that project, the two packages (log4j. jar and commons-logging.jar) are lost, how is his internal processing? The following are the original instructions in the Apache document:

1. Look for a Configuration Attribute of this factory namedorg.apache.commons.logging.Log(For backwards compatibility to pre-1.0 versions of this API, an attributeorg.apache.commons.logging.logIs also consulted ). configuration attributes can be set explicitly by Java code, but they are more commonly set by placing a file named commons-logging.properties in the classpath. when such a file exists, every entry in the properties file becomes an "attribute" of the logfactory. when there is more than one such file in the classpath, releases of commons-logging prior to 1.1 simply use the first one found. from release 1.1, each file may definepriorityKey, and the file with the highest priority is used (no priority definition implies priority of zero ). when multiple files have the same priority, the first one found is used. defining this property in a commons-logging.properties file is the recommended way of explicitly selecting a log implementation.
2. Look for a system property namedorg.apache.commons.logging.Log(For backwards compatibility to pre-1.0 versions of this API, a system propertyorg.apache.commons.logging.logIs also consulted ).
3. If the log4j logging system is available in the application class path, use the corresponding Wrapper class (log4jlogger ).
4. If the application is executing on a JDK 1.4 system, use the corresponding Wrapper class (jdk14logger ).
5. Fall back to the default Simple logging wrapper (simplelog ).

Therefore, from the above perspective, commons-logging plays a major role in ensuring that the project has a log implementation class, logs are recorded. (Check whether the configuration is defined or not. Check whether log4j is available. check whether it is 1.4jdk. If not, use simplelog ).

But in this way, because WebSphere uses commons-logging, it sometimes conflicts with its own projects. There are a lot of online solutions, IBM also provides documents to solve this problem.

Therefore, I think we should not use commons-logging during the development, indicating that it is not okay to use only log4j. During the development, logs must be required, there is no need for commons-logging to ensure that there must be a log implementation class. The log is generated by log4j. Do not let the classloader go to the east to find the West, it is a waste of time to understand its classloader in WS.

From: http://squll.blogbus.com/logs/47802699.html