IntroductionWelcome to the second in our blog series of using alternative logging frameworks with application servers. This entry will focus on WebLogic, specifically 12c, and configuring it to use Log4j and SLF4J with Logback.
If you missed the first part of this series, find it here: Part 1 - GlassFish
As ever, a small disclaimer with the environment I used: 64-bit Linux Distro, WebLogic 12.1.3, Logback 1.2.2, SLF4J 1.7.7, Log4j 2.0.2, and web-app version 3.1, with all coding for the tests done in NetBeans 8.0.
I'll be assuming you have created a basic WebLogic domain, so let's get started with Log4j.
Log4j
As with when configuring GlassFish to use Log4j, we must copy across the log4j-api-2.0.jar and log4j-core-2.0.jar files to the domain; download Log4j and copy these JARs to $MW_HOME/user_projects/domains/$domain_name/lib. From the $MW_HOME/wlserver/server/lib/ directory, copy the wllog4j.jar file over to the same domain lib directory as before. WebLogic automatically appends any JARs located in the domain's lib directory to the domain's classpath.
With that done, create a Log4j2 properties file and place it in the domain's root directory ($MW_HOME/user_projects/domains/$domain_name). I named mine log4j2.xml, and you can find it below (it's the same one that I used in the last blog); it's a simple configuration that outputs log messages of any level to the console:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm} [%t] %-5level %logger{36} - %msg%n"/>
</Console>
</Appenders>
<Loggers>
<Root level="trace">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration> Like this:
./startWebLogic -Dlog4j.configurationFile=log4j2.xmlTo check that it's working, let's use the same test as in my previous blog (if it ain't broke...), namely deploying a simple servlet that makes a call at each log level. Create a simple Java web application in NetBeans (or the IDE of your choice), add a servlet to the project, and do the following:
- Import the two Log4j JARS, log4j-api-2.0.jar and log4j-core-2.0.jar, into the project, and import the package into the servlet:
import org.apache.logging.log4j.*; - Declare and initialise a logger:
private static Logger logger = LogManager.getLogger(TestServlet.class.getName());- And alter the processRequest method to look like this:
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
response.setContentType("text/html;charset=UTF-8");
try (PrintWriter out = response.getWriter())
{
logger.trace("Tracing a possible error");
logger.debug("Debugging a possible error");
logger.info("Gathering info on the possible error");
logger.warn("Warning you about the possible error");
logger.error("The error is indeed an error");
}
}<html>
<head>
<title>Testing</title>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<form name="testForm" action="TestServlet">
<input type="submit" value="push me!" name="testybutton" />
</form>
</body>
</html>SLF4J with Logback
WebLogic comes bundled with a version of SLF4J, which can make things slightly difficult when attempting to use your own (likely more up to date) version of SLF4Jwith Logback. To do so, you have to essentially tell WebLogic to ignore its version of SLF4J, and use a version bundled with your application.
To this end, let's use the same application that we used for Log4j, though with the following modifications:
- Download SLF4J and Logback, and import the following three JARs into the project:
- slf4j-api
- logback-core
- logback-classic
- Import the following two packages into the servlet
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;- And alter the logger initialisation to this:
private static Logger logger = LoggerFactory.getLogger(TestServlet.class.getName()); As noted earlier, we needed to tell WebLogic to use the bundled version of SLF4J and its binding to logback. The prefer-web-inf-classes tag does just this, and you will later even evidence of this in the logs; we are not overwriting the pre-existing SLF4J binding, we are including another with the application and telling WebLogic to prioritise using that one.<?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">
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
</wls:weblogic-web-app>
Build the project, but do not start WebLogic and deploy it yet; we still need to create a configuration file for WebLogic to use.
Create a Logback properties file, logback.xml, and place it in the domain root ($MW_HOME/user_projects/domains/$domain_name). Here is a basic one that just prints to the console:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="TRACE">
<appender-ref ref="STDOUT"/>
</root>
</configuration> ./startWebLogic -Dlogback.configurationFile=logback.xml And so concludes the second part in this logging series, hopefully giving you a starting point for using Log4j or Logback with WebLogic. Next up on the list is Wildfly, so stay tuned for that. Feel free to check out some of our other blogs on WebLogic in the meantime:
Weblogic - Dynamic Clustering in practice
WebLogic 12c Does WebSockets - Getting Started
Common WebLogic Problems
