Alternative Logging Frameworks for Application Servers: WebLogic
Join the DZone community and get the full member experience.
Join For FreeIntroduction
Welcome to the second in the 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.
The first part of this series can be found 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>
Configuration
done! Simply tell WebLogic to use your configuration file by starting it with
the following option:-Dlog4j.configurationFile=log4j2.xml
Like this:
./startWebLogic -Dlog4j.configurationFile=log4j2.xml
Testing
To 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());
With
the main application configured for logback, we next need to create a weblogic.xml
file under the WEB-INF directory of the project, and populate it with
this:
<?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>
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.
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
Wrapping Up
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
Published at DZone with permission of Andrew Pielage. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
What ChatGPT Needs Is Context
-
Clear Details on Java Collection ‘Clear()’ API
-
A Data-Driven Approach to Application Modernization
-
Five Java Books Beginners and Professionals Should Read
Comments