Posted on

Creating Oracle Weblogic deployment plans

Creating deployment plans

Deployment plans are part of the JSR-88 deployment standard, although not explicitly stated in this standard. A deployment plan is an XML document that defines a custom WebLogic Server deployment environment. This configuration can be used to override the specific settings defined into the application archive.

There are many reasons why you may not want to modify an application archive, one of which is testing.  For example, if you have successfully completed testing for a particular version of an application, it is desirable to keep the application archive unmodified between environments so you can have increased confidence that the application will behave the same in multiple environments as it is promoted.  Another reason might be portability.  You could have one generic JEE application archive without proprietary deployment descriptors and put all of those proprietary deployment descriptor values outside of that archive.

There are several alternatives for creating a deployment plan: start by setting your environment to include the WLS classpath:

C:\wls1211_dev\user_projects\domains\base_domain\bin>setDomainEnv.cmd

Then, you can use the PlanGenerator utility to create a deployment plan for your application

java weblogic.PlanGenerator -all WLSDemo.ear

 

Generating plan for application WLSDemo.ear

Export option is: all

Exporting properties…

Saving plan to C:\wls1211_dev\user_projects\domains\base_domain\bin\plan.xml…

<8-ago-2012 11.52.48 CEST> <Info> <J2EE Deployment SPI> <BEA-260072> <Saved configuration for application, WLSDemo.ear>

Let’s check the file plan.xml which contains all the application specific settings. We will not include the whole plan.xml file here which is quite verbose; however we will include as example, how to customize some parameters contained in it.

A deployment plan is an XML file which basically defines some variables using unique names and assigns the variables values to specific elements of the custom deployment descriptors. The specific XML elements are referenced using XPath expressions.

Example: customizing the Web application root context

Open the file plan.xml file and edit it with a text editor. Next, locate the following <variable> element:

<variable>

  <name>WeblogicWebApp_ContextRoots_xxxxxxxxxxxxxx</name>

  <value xsi:nil=”true”></value>

</variable>

Note that the xxxxxxxxxxxxxx will actually be an unique identifier created by the Plan Generator in order to define an unique name for the variable. In the following example, we will replace it with a meaningful name that will be referenced through the file.

Now edit the above snippet section, so that it looks like this:

<variable>

  <name>WeblogicWebApp_CustomContext</name>

  <value>/newcontext</value>

</variable>

Futher down in the file, locate the <variable-assignment> element which points to “weblogic-web-app/context-root” XPath expression and change the variable name to : “WeblogicWebApp_CustomContext” so that it matches with your variable:

<variable-assignment>

  <name>WeblogicWebApp_CustomContext</name>

  <xpath>weblogic-web-app/context-root</xpath>

  <origin>planbased</origin>

  <operation>replace</operation>

</variable-assignment>

Also notice, we have included an additional “replace” operation in it, which will obviously replace the default context with the new one (“/newcontext”).

Save the plan.xml file. What we just did is overriding the context-root element in the WebLogic Server web application deployment descriptor- weblogic.xml. The new context root is “newcontext”.

Fine, now switch to the administration console and choose to update the application from the Deployments menu.

Click the Change Path button associated with the Deployment plan path as shown:

Now select the radio button for the new plan.xml file and click Next. If necessary, use the hyperlinks next to the Current Location field to navigate to the <APP_HOME> directory.

In the next screen select the radio button “Redeploy this application using the following deployment files”. Then click Finish. Now your application should be accessible using the new web context (newcontext).

Example: customizing the JDBC modules

The first example we have covered is good starting point for creating some more customization. One real world example could be to provide a deployment plan which updates the information contained in a JDBC module that is part of your application. It is likely to happen that your application will be distributed in different environments (development/production/test) where different databases are used. For example:

<wls:resource-description>

        <wls:res-ref-name>JDBCOracleModule</wls:res-ref-name>

        <wls:jndi-name>jdbc/OracleModule</wls:jndi-name>

</wls:resource-description>

In this example, if we were to change the JNDI name where the JDBC module is bound, we would need modifying the XML descriptors where the JNDI name is defined (See Chapter 7 at section “Referencing resources in the JNDI tree”).

By using a deployment plan instead, you could simply modify the value of the JDBC resources in plan.xml and update the application accordingly. Let’s see a concrete example which continues our discussion started in Chapter 7 “JNDI Portability”: in particular let’s suppose we want to change the JNDI binding of our TestEJB when porting the application in production, by changing it from “jdbc/OracleModule” to “jdbc/ProductionOracleModule”.

Start by generating a plan.xml deployment plan using the PlanGenerator utility. Now open your plan.xml and set the value element for your data source in a variable:

<variable>   

   <name>MyDataSource_binding</name>  

   <value>jdbc/ProductionOracleModule</value>

</variable>

The above variable name (“MyDataSource_binding”) needs to be referenced in a corresponding variable-assignment stanza which sets the correct JNDI binding for your resource:

<module-override>

    <module-name>TestEJB.jar</module-name>

      . . . . .

      <uri>META-INF/weblogic-ejb-jar.xml</uri>

       <variable-assignment>

        <name>MyDataSource_binding</name>

        <xpath>/weblogic-ejb-jar/weblogic-enterprise-bean/[ejb-name=”TestEJB”]/resource-description/[res-ref-name=”MyDataSource”]/jndi-name</xpath>

      </variable-assignment>

    </module-descriptor>

</module-override>             

What if the data source is referenced as well in Web applications, let’s say it’s injected in a Servlet? no worry! You can provide a module-override also for the Web module; in this case we will override the weblogic.xml:

<module-override>

    <module-name>wls.war</module-name>

       . . . .

       <uri>WEB-INF/weblogic.xml</uri>

       <variable-assignment>

           <name>MyDataSource_binding</name>

           <xpath>/weblogic-web-app/resource-description/[res-ref-name=”jdbc/ ProductionOracleModule “]/res-ref-name</xpath>

           <origin>planbased</origin>

       </variable-assignment>

    </module-descriptor>

</module-override>             

Generating the deployment plan using the administration console

If you don’t feel like using the command line to generate the deployment plan, you can do this step using the administration console instead. Navigate to your application from the Deployments option:

Then click on your application and move to the Configuration tab. In the lower part of the screen you will be able to change the application settings such as the Context Root path. Change this value to a new context path and save.

Once you have modified some values of the configuration, the deployment plan assistant will kick in, asking you to save these changes in a deployment plan. All you have to do is providing a convenient location for the file (highly suggested to use the name plan.xml).

The next step will be customizing the plan.xml file, as we showed earlier and updating your application using that file.

 

Posted on

Deploying applications using the Autodeploy folder

Oracle Weblogic Auto-deployment can be useful when performing development and continuous integration tests.

When the WebLogic Server instance is running in development mode, applications and modules in the autodeploy folder are automatically deployed. The folder which is used for autodeployment is WL_HOME>/user_projects/domains/domain/autodeploy

Due to Windows’ file locking limitations, if an application is exploded, all the modules within the application must also be exploded too. In other words, you cannot use auto-deployment with an exploded application or module that contains a JAR file.

Triggering redeployment (or undeployment) of an archived application is pretty easy: just replace the archive with the new one to trigger redeployment or delete it in order to undeploy the application.

Triggering redeployment of an exploded application is a bit more complex due to OS file locking limitations. In order to trigger redeployment, you need to update the timestamp (in Unix you can just use the touchcommand) of a marker file namedREDEPLOY.

The only thing you need to pay attention is the location where WebLogic server looks for the REDEPLOY marker files: The following table will assist you:

Application type

Location of REDEPLOY file

Enterprise Application

META-INF top-level directory

Web Application

WEB-INF directory

EJB Application

META-INF top-level directory

Application Server Comparison

As for Oracle WLS, also JBoss EAP 6 by default uses a marker file to trigger redeployment of an exploded application. Just the name changes: for JBoss users it’s application-name.dodeploy and needs to be placed in the deployments folder of your standalone server.

Posted on

Deploying applications with Oracle WLS

Deploying applications with Oracle WLS can be done using a variety of instruments:

  • Using the Eclipse environment: this is the favourite option for developers, as it allows deploying applications as you are coding, using just one instrument.
  • Using the WebLogic console: this is a multi-purpose option which is recommended in case you are deploying your applications from/to a remote environment or if you don’t know the exact name or location where your deployments are.
  • Using the WLST scripting language: this option comes to your rescue in case you have to perform some batch deployments, or you want to automate your deployments while adding some logic to it. This option is discussed in the chapter 10 “Managing Oracle WLS with WLST”.
  • Using the class weblogic.Deployer: thisis, as well, a shell script solution which has been available since the very first releases of WLS. It can be still useful if you don’t need all the power of the WLST scripting language.

Deploying applications from Eclipse

Once that you have installed the OEPE, you should be able to see, in the Server Tab, the Oracle WebLogic Server icon:

Right-click on it and choose “Add or Remove” option; this will allow you delivering applications on your server.

If you want to specify the list of servers on which your application will be deployed, right-click on the application server and choose “Properties”. Expand the WebLogic | Publishing | Advanced option as depicted by the following picture:

From there, you can choose which servers will be elected as Target servers for your application. Once you are done, return to the Server icon and Right-click and choose “Publish”.

 

Posted on

Developing applications with Oracle WLS

The WebLogic Server complete implementation of the Java EE 6.0 specification provides a standard set of APIs for creating distributed Java applications using a wide variety of services (such as databases, messaging services, and connections to external enterprise systems). It also supports the Spring Framework, a programming model for Java applications which provides an alternative to many aspects of the Java EE model.

Although the focus of this book is not on the development of applications, we will guide you through a set of topics which are important to know if you want to develop fully portable Java EE applications or simply if you want to kick-start your first Oracle WLS project.

  • The first part of this chapter covers the installation of a development environment which is an Eclipse on steroids, specifically designed for Oracle WLS.
  • In the second part we will learn some peculiar development features related to the JPA and JNDI API which are essentials when porting applications from other application servers to the WLS and vice versa.
  • In the last block, we will learn how to create shared libraries which can expand the default core server libraries.

Installing a development IDE for Oracle WLS

There are several alternatives for developing applications on Oracle WLS: in this recipe we will show how to download and install the Oracle Enterprise Pack for Eclipse (OEPE) which is an Eclipse based environment which contains all the required plugins for developing apps with Oracle WLS.

Oracle Enterprise Pack for Eclipse (OEPE) is installed out of the box in your distribution if you have installed it using the 32 bit Full Installer option.

In order to install the Oracle Enterprise Pack for Eclipse (OEPE),follow these simple steps:

  1. Move to the download page at:  http://www.oracle.com/technetwork/developer-tools/eclipse/downloads/index.html
  2. Download Oracle Enterprise Pack for Eclipse Standalone Installers suited for your OS.

The Oracle Enterprise Pack for Eclipse Standalone installers includes a preconfigured version of Eclipse and the OEPE plugins. Installing OEPE just requires unzipping it to a folder of your choice. Once done with it, start Eclipse by running the eclipse (eclipse.exe for Windows) command.

The first thing we will need to do is defining a new WebLogic Server. This can be achieved from the Eclipse File menu, by selecting New | Server:

Choose the latest stable release and, in the next screen, select your WebLogic home and Java home:

Click on Next. In the following screen, point to your Oracle WLS Domain directory:

Click Finish and verify that the Oracle WebLogic Server has been included in the Server Tab:

Posted on

Configuring JMS Services

Oracle WLS provides its own messaging system that fully implements the JMS specification; it also provides other configuration and programming options that go well beyond standard Enterprise-class messaging features.  Here are the key components of Oracle WLS JMS Architecture:

 

  • JMS Server: A JMS server is a management entity and container for JMS destination-related resources that reside on a single WLS instance. A WLS JMS Server instance can host zero or more JMS servers and can serve as a migration target for zero or more JMS servers. 
  • JMS Modules: JMS modules contain configuration resources such as queue and topic destinations, distributed destinations and connection factories. In WebLogic Server, these resources are configured inside the DOMAIN_HOME/config/jms directory.
  • JMS Producers/Consumers: This is a piece of software that either produces messages to destinations or consumes messages from destinations.
  • Persistent Store: This is used for storing the Data (Messages). It can be either a user defined Persistent Store or a Default Persistent store.

Here is a graphical view of the concepts exposed so far, which shows two JMS Servers each one containing a JMS module where JMS destinations are registered:

 

Steps to configure JMS resources

In order to create JMS resources, you need to perform a set of activities which include:

  1. Creating a JMS Server
  2. Creating a JMS Module
  3. Creating JMS Connection factories
  4. Creating JMS Destinations

In the following sections, we will create the first mandatory JMS resource, which is the JMS Server.

Creating a JMS Server

  1. Expand the Services option from the left menu and select Messaging | JMS Servers.
  2. Click New in the JMS Servers table. In the next screen, enter values for the following configuration parameters:

Specify the following mandatory settings:

  • Name: The name of the JMS server.
  • Persistent Store: A JMS store can be file-based or database. Database is usually a bit slower, but can take advantage of high-availability or failover solutions offered by the database. A value of “none”, means that the JMS server will use the default persistent store that is configured on each targeted WLS instance.

If you don’t want to rely on the default Persistent Store, hit the “Create a New Store” button. This will continue navigation to another screen where you can select File Store or JDBC Store.

If you selected JDBC Store, in the next screen you need to select a JDBC data source or configure a new JDBC data source for the store.

– If you selected File Store, in the next screen you need to enter the path name for your storage (mind it, the directory must exist on your system, so be sure to create it before completing this step).

Complete this section by targeting a JMS server to an Oracle WLS server:

Click Save to complete the JMS Server creation.

 

Posted on

WLDF: How to create Watches and Notification

oracle weblogic book oracle weblogic books

The Oracle Weblogic Watch and Notification system can be used to create automated monitors that observe specific diagnostic state and send notifications based on configured rules. More in detail:

  • Watch: this component is used to monitor the MBean attributes.
  • Notification: this component includes the events which are triggered based on the values set in the watch. There can be different types of alert like SNMP alerts, JMS Messages, JMX notifications etc.

 

Create a new Notification

In order to create a Notification, you need at first a Diagnostic Unit, such as the Heap Diagnostic that we set up in the earlier section.

Select your Diagnostic Unit and choose, from the Configuration Menu, the Watches and Notifications submenu. From there, select the “Notification” tab and click on the “New” button as depicted by the following picture:

oracle weblogic book oracle weblogic books

In the next screen, we will be choosing the type of notification we will use among Mail (SMTP), JMS Messages, JMX Notification, SNMP Trap and Diagnostic Image. In our example, we will pick up JMS Messages from the list, which means that notification messages will be delivered using the JMS system:

oracle weblogic book oracle weblogic books

Next, specify the notification name and if your notification will be enabled by default:

oracle weblogic book oracle weblogic books

The following screen will be tailored for your notification type: if you selected to receive a JMS notification, then you have to enter the Queue JNDI name and the Connection Factory JNDI name which will be used when Watch events are triggered.

oracle weblogic book oracle weblogic books

Click Finish to create your Notification. In the next part, we will show how to associate the Notification with a Watch component.

Create a new Watch

In this section we will show how to create a watch that will monitor the attributes of a specific MBean. Select your diagnostic unit and choose, from the Configuration menu, the Watches and Notifications submenu. From there, select the “Watches” tab and click on the “New” button:

oracle weblogic book oracle weblogic books

The Watch will be based on a set of “Collected Metrics”, therefore, check that this option is selected and that it is “enabled” as shown by the following picture:

oracle weblogic book oracle weblogic books

Click Next to continue. The Watch will need a rule expression to be checked, so in the following screen choose to add a new rule expression:

oracle weblogic book oracle weblogic books

Creating a new Rule Expression is quite easy as it can be done by means of an intuitive wizard and some basic operators (“=”,”>”,”<” etc.). Before doing that, in next step we will need to select the MBean we are going to monitor: in our example, weblogic.management.runtime.JVMRuntimeMBean. Done with the MBean, in the next screen we will select the attribute you want to monitor and specify a value for that rule. As shown by the following picture, we are going to watch the HeapSizeMax attribute, specifying as rule “> 200”:

oracle weblogic book oracle weblogic books

The last screen will recap your current rule, letting you to add some more expressions, combine with existing rule expressions or simply finish the rule creation.

oracle weblogic book oracle weblogic books

As last effort, select the JMS Notifier from the list on the left side and click on “>” or “>>” so that it is associated with the watch created. Once done, click Finish.

oracle weblogic book oracle weblogic books

Target the WLDF to any of the servers where MBeans will be monitored. Now check server logs, where you can verify that your alarms are being triggered.

Posted on

Using Oracle Weblogic Diagnostic Framework

oracle weblogic book oracle weblogic books

WLDF (WebLogic Diagnostics Framework) is a group of components that work together to collect, archive, and access diagnostic information in real-time.

The following components are part of the WLDF:

  • Diagnostic Image Capture: creates a diagnostic snapshot from the server that can be used for post-failure analysis.
  • Archive: captures and persists data events, log records and metrics from server instances and applications.
  • Instrumentation: adds diagnostic code to WebLogic Server instances and the applications running on them to execute diagnostic actions at specified locations in the code. The Instrumentation component provides the means for associating a diagnostic context with requests so they can be tracked as they flow through the system.
  • Harvester: captures metrics from run-time MBeans, including WebLogic Server MBeans and custom MBeans, which can be archived and later accessed for viewing historical data.
  • Watches and Notifications: provides the means for monitoring server and application states and sending notifications based on criteria set in the watches.
  • Logging services: manage logs for monitoring server, subsystem, and application events.

 

 

 

 

 

 In this section we will introduce you how to use the Administration console to achieve diagnostic information about your servers; if you need further information about WLDF we suggest you having a look through the Oracle documentation: (http://docs.oracle.com/cd/E24329_01/web.1211/e24426/intro.htm)

Creating a new Oracle Weblogic Diagnostic Module

In order to create a new Diagnostic module, perform the following steps:

1.       Expand the “Diagnostics” option from the Domain Structure. From there, select the “Diagnostic modules” and click on “New”.

2.       In the next screen, choose a name and a description for your module: in this example we will show how to create a diagnostic module for collecting information about JVM Heap:

oracle weblogic book oracle weblogic books

Now click on “OK”. You will return to the Summary page.

Our Diagnostic module has been created; however, it still has no metric associated. Click on the Heap Diagnostic module and select the Configuration tab and Collected Metrics sub tab:

oracle weblogic book oracle weblogic books

Click on “New” in order to create a new metric. In the next screen, you need to choose between “Server runtime” and “Domain runtime” metrics. (The former means that metrics will be collected at server level; the other option, Domain Runtime, provides access to the Domain Wide metrics and is available only for the Admin Server):

oracle weblogic book oracle weblogic books

Next, select the MBean you want to collect metrics for. For example, if you are behind JVM metrics, select ‘weblogic.management.runtime.JVMRuntimeMBean’ as shown:

oracle weblogic book oracle weblogic books

In the next screen, specify which attribute of the MBean you want to monitor. In our case, we will select ‘HeapSizeMax and click “Finish”.

oracle weblogic book oracle weblogic books

Finally, from the summary view of WLDF Modules, select the target instance which you want to monitor (for example WLSNode1) and click Finish.

Posted on

How to view Oracle Weblogic logs from the Console

oracle weblogic book oracle weblogic books

This quick recipe shows how you can view Oracle Weblogic logs from the Administration Console.

Usually, system or resource loggings are monitored with an operating system tool/shell (like the Unix’s tail -f command). However, the Oracle WLS Administration Console provides a Log Viewer for all log files traced by a domain. To reach the Log Viewer, perform the following steps:

1.       Expand from the left panel the option Diagnostic and, from there, click on the Log Files option.

2.       Select the Service you are interested to view as shown by the following picture:

oracle weblogic book oracle weblogic books
The Log Viewer can find and display the messages based on a large set of attributes (including date, subsystem, severity, machine, server, thread, user ID, transaction ID etc ). It can also display messages as they are logged or search for past log messages. Here’s a snapshot of the Admin Server’s logs:

oracle weblogic book oracle weblogic books

Posted on

Configuring Oracle Weblogic Services Logging

oracle weblogic book oracle weblogic books

Besides the core server logs, there are specialized logs for some built-in Services running in Oracle WLS Server such as:

  • HTTP Logs
  • Transaction Manager Logs
  • Weblogic Auditing provider
  • Data source Logging
  • JMS Logging

Configuring Oracle Weblogic HTTP Logs

The HTTP subsystem keeps a log of all HTTP transactions in a text file. The default location and rotation policy for HTTP access logs is the same as the Server log. You can set the attributes that define the behavior of HTTP access logs for each server you define.

1.       Navigate to the server you want to configure and pick up the Logging upper tab.

2.       From there, select the lower “HTTP” tab as showed:

oracle weblogic book oracle weblogic books

HTTP access logs are stored by default on the logs/access.log file and are rotated by size every 500KB. You can alternatively choose to rotate them by time.

Configuring Oracle Weblogic Transaction Logs

Each server has a transaction log which stores information about committed transactions, (coordinated by the server), that may not have been completed. WebLogic Server uses the transaction log when recovering from system crashes or network failures. You cannot directly view the transaction log—the records are in a binary format and are stored in either the default persistent store or a JDBC TLOG store for the server.

You can find the Transaction log configuration by entering into the Server view and, from there, choose the Configuration upper tab and the Services lower tab:

oracle weblogic book oracle weblogic books

The default transaction storage is on the file system; you can opt for a different storage by selecting the Type combo box which will let you select a data source that can be used as Transaction storage.

If no Directory is specified for the default file store, it defaults to: MW_HOME\user_projects\domains\domain-name\servers\server-name\data\store\default

Configuring Oracle Weblogic Auditing Logs

The Auditing provider records information from a number of security requests, which are determined internally by the WebLogic Security Framework. The WebLogic Auditing provider also records the event data associated with these security requests, and the outcome of the requests. Configuring an Auditing provider is optional. The default security realm (myrealm) does not have an Auditing provider configured.

All auditing information recorded by the WebLogic Auditing provider is saved in the file DefaultAuditRecorder.log which is located in:

MW_HOME\user_projects\domains\domain-name\servers\servername\logs

Configuring Oracle Weblogic Data source Logs

The JDBC subsystem records various events related to JDBC connections, including registering JDBC drivers and SQL exceptions. The events related to JDBC are now written to the server log (e.g. when connections are created or refreshed or when configuration changes are made to JDBC objects).

You can configure the data source logging by navigating to your server and selecting the Logging upper tab and the Data Source lower tab:

oracle weblogic book oracle weblogic books

Configuring Oracle Weblogic JMS Logs

JMS logging is enabled by default when you create a JMS server; however, you must specifically enable it on message destinations in the JMS modules targeted to the JMS server (or on the JMS template used by destinations).

JMS server log files contain information on basic message life cycle events, such as message production, consumption and removal. When a JMS destination hosting the subject message is configured with message logging enabled, then each of the basic message life cycle events will generate a message log event in the JMS message log file.

The default message log is located in the logs directory, below the server instance root directory: MW_HOME\user_projects\domains\domain-name\servers\servername\logs\jmsServers\SERVER_NAME\JMSServer\jms.messages.log

You can change the default Log file name and Rotation Type by entering into the Services | Messaging left panel; from there, select JMS Server and the server you want to operate with.

From the JMS Server GUI, enter into the “Logging” upper tab menu. The follow picture shows the Logging panel where you can customize your JMS Logging: 

oracle weblogic book oracle weblogic books

Posted on

Configure Oracle Weblogic to use log4j

oracle weblogic book oracle weblogic books

As we said, by default Oracle Weblogic server use the JDK Logging implementation. You can anyway switch to Log4j (http://logging.apache.org/log4j) configuration if you feel more comfortable with it. That will anyway require a few steps to complete it:

1.       At first, from the Advanced Logging screen, select Log4j as the Logging implementation as shown by the following picture:

oracle weblogic book oracle weblogic books

2.       Now enter your Server’s configuration screen and select Configuration | Server Start. From there, add as properties the log4j configuration file name and set the property weblogic.log.Log4jLoggingEnabled to true as shown by the following snapshot:

oracle weblogic book oracle weblogic books

Remember that the log4j.properties (or log4j.xml) file needs to be included into Weblogic classpath; thus, supposing that you have placed it into the folder “C:\Weblogic\user_projects\domains\base_domain\config”, then you need adding this directory into the server Classpath text item.

The following log4j.properties defines a RollingFileAppender which will write logs to your domain root directory:(C:\Weblogic\user_projects\domains\base_domain)

log4j.appender.rollingFile=org.apache.log4j.RollingFileAppender  log4j.appender.rollingFile.File=mylog.log  log4j.appender.rollingFile.MaxFileSize=2MB  log4j.appender.rollingFile.MaxBackupIndex=2  log4j.appender.rollingFile.layout = org.apache.log4j.PatternLayout  log4j.appender.rollingFile.layout.ConversionPattern=%p %t %c - %m%n  log4j.rootLogger = INFO, rollingFile

 Last effort, since WebLogic Server does not load any Log4j library in your domain, will be to include log4j in the DOMAIN_HOME/lib subdirectory. Place there a Log4j implementation (log4j-X.X.X) and Weblogic’s Log4j libraries (wllog4j.jar) which are part of the server distribution.