I'd like configure a centralized logging into WebLogic 12C. According to the business requirements I have to use Syslog in the production environment and I have to provide custom (eg. file, console log) in the developer and test environment. And I'd like to handle only 1 centralized log configuration for each applications in the domain. The applications use SLF4J API. In Glassfish 3.1 and WebLogic 10.3.5 works well when I put the Logback or Log4J bridge and their implementation into the domain lib and I configure them. But in WebLogic 12C I've ran into much proplem. The main problem is WL already contains SLF4J binding among the modules (and I don't want to modify the WL, or shall I?). So when I put a second binding the SLF4J can't initialize it/them and uses the default JUL logger. I've also tried to configure the Log4J logger via the WL Admin console but only the server messages goes to the Log4J logger the messages of the applications still goes to JUL. (http://docs.oracle.com/cd/E24329_01/web.1211/e24428/config_logs.htm#i1011558, https://forums.oracle.com/forums/thread.jspa?threadID=1037672)
So how can I maintain only 1 Log4J or Logback (or any other solution that satisfies the reqs above) configuration in a WebLogic12C domain?
Thx for the help!
If you want to use SLF4J and Logback here are some instructions:
You have to bundle the SLF4J and Logback artifact you wish to use with your application (This is the only working solution i found! I know that normaly one would NOT bundle an SLF4J binding!). Also bundle an weblogic.xml (WebLogic specific web.xml) in your WAR project and the weblogic-application.xml (WebLogic specific application.xml) in your EAR project (in case you have both use both, otherwise select the matching one). Again both EAR AND WAR have to provide the following artifacts:
Content of those xml files:
weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd
http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<!-- GERMAN: http://www.torsten-horn.de/techdocs/jee-oracleweblogic.htm -->
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
</wls:weblogic-web-app>
weblogic-application.xml
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<!-- GERMAN: http://www.torsten-horn.de/techdocs/jee-oracleweblogic.htm -->
<prefer-application-packages>
<package-name>org.slf4j.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>org/slf4j/impl/StaticLoggerBinder.class</resource-name>
</prefer-application-resources>
</weblogic-application>
With those xml files you tell WebLogic to prefer the bundled versions over the ones WebLogic comes with (WAR). For EARs this can be done on a per package/resource basis. More precise the order of the classloaders are changed for the specified packages.
While bundling the SLF4J and Logback jars with only the EAR or the WAR will get you an error or no logging at all, you will also get an warning when bundling the artifacts in both. If anybody has improvement ideas, feel free to drop a comment!
As far as I understand EAR and WAR files have different class loaders in WebLogic, even if the WAR is bundled with the EAR. Thats why you cannot share this libs between them, am I right?
Configuring Logback: To be able to change the logback configuration on runtime, you have to place a logback.xml somewhere in the WebLogic classpath. I found a lot of websites, telling me that WebLogic loads resource files from the domain directory, but in my case it was not in the classpath, so I had to add it via the server start script to the global classpath (This will affect the logback settings forEVERY domain!). Again, any improvements are welcome!