Alternative Logging Frameworks for Application Servers: WebLogic

DZone 's Guide to

Alternative Logging Frameworks for Application Servers: WebLogic

Andrew Pielage

Sep. 12, 14 · Java Zone ·

Free Resource

Like (0)

Comment (0)

Save

{{ articles[0].views | formatCount}} Views

Introduction
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");  
      }  
 }

This will print out log statements when a call is made to the servlet. Add a button to the home page of your web application, index.html, to afford you a simple means of calling the servlet:

<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>

Build and deploy the application to WebLogic, and you should find the messages in the out log file of the server the application was run on, e.g. Server-0.out. For those of you new to WebLogic, these log files can be found at: $MW_HOME/user_projects/domains/$domain_name/servers/$server_name/logs

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>

And with that, besides a start-up parameter, you're done! This will cause all log messages of any level to be printed to the server's out log file. Start WebLogic as below, and you're good to go!

 ./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

DOWNLOAD

Topics:

Like (0)

Comment (0)

Save

{{ articles[0].views | formatCount}} Views

Published at DZone with permission of Andrew Pielage . See the original article here.

Opinions expressed by DZone contributors are their own.

Alternative Logging Frameworks for Application Servers: WebLogic

Alternative Logging Frameworks for Application Servers: WebLogic

Java Partner Resources

{{ editionName }}

{{ parent.title || parent.header.title}}

{{ parent.linkDescription }}

Alternative Logging Frameworks for Application Servers: WebLogic

Alternative Logging Frameworks for Application Servers: WebLogic

Like This Article? Read More From DZone

Java Partner Resources

{{ editionName }}

{{ parent.title || parent.header.title}}

{{ parent.linkDescription }}