DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

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

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
  1. DZone
  2. Coding
  3. Java
  4. Alternative Logging Frameworks for Application Servers: WebLogic

Alternative Logging Frameworks for Application Servers: WebLogic

Andrew Pielage user avatar by
Andrew Pielage
·
Sep. 12, 14 · Interview
Like (0)
Save
Tweet
Share
13.87K Views

Join the DZone community and get the full member experience.

Join For Free

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

Web application Log4j

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

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: