Thursday Oct 18, 2012

How to Convert a PFX Certificate into a JKS Certificate to configure it on WebLogic

To convert a pfx cert file to a jks file, please follow these instructions:

1. Set up the environment for the domain, by executing the script, typically located at $DOMAIN_HOME/bin.

$ . ./

2. Use OpenSSL to check the pfx certificate's content.
$ openssl pkcs12 -in <certificate.pfx> -out KEYSTORE.pem -nodes

At this point, a password for the pfx file will be requested.

Expected output:

$ openssl pkcs12 -in <certificate.pfx> -out KEYSTORE.pem -nodes
Enter Import Password:
MAC verified OK

3. Open KEYSTORE.pem file, from step 2. This should look similar to this:You will find three certificates on it and the private key:

Bag Attributes
Microsoft Local Key set: <No Values>
localKeyID: 01 00 00 00
friendlyName: le-36c42c6e-ec49-413c-891e-591f7e3dd306
Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
X509v3 Key Usage: 10
Bag Attributes
localKeyID: 01 00 00 00
friendlyName: *
subject=/serialNumber=sj6QjpTjKcpQGZ9QqWO-pFvsakS1t8MV/C=US/ST=Missouri/L=CHESTERFIELD/O=Oracle_Corp, Inc./OU=Oracle/CN=*
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA

Bag Attributes
friendlyName: GeoTrust Global CA
subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Bag Attributes: <Empty Attributes>
subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

4. Identify and store contents from KEYSTORE.pem certificate, to proceed and create jks files:

At this point, you will find three certificates on KEYSTORE.pem and the private key.

4.1 Private Key.

To identify the private key, look for the following headings:


Both above mentioned tags will be surrounded the private key. Go ahead and save the content of it into a file called: my_key_pk.pem. This has to include the headings.

Expected file:


4.2 Root Certificate.

To identify the Root Certificate, look for the following headings:

subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

Subject and issuer must be the same. Go ahead and save the content of it into a file called: my_key_root.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

4.3 Intermediate Certificate.

To identify an Intermediate Certificate, look for the following heading:

subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

 Subject and issuer are different only on the CN. Go ahead and save the content of it into a file called: my_key_intermediate.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

NOTE: This certificate is optional and there are some cases where it'll not be present. If this is the case, go ahead and skip this step. In any other case, this needs to be added to the identity keystore jks file.

4.4 Server Certificate.

 To identify a Server Certificate, look for the following heading:

subject=/serialNumber=sj6QjpTjKcpQGZ9QqWO-pFvsakS1t8MV/C=US/ST=Missouri/L=CHESTERFIELD/O=Oracle_Corp, Inc./OU=Oracle/

        A server certificate includes a heading called Friendly Name. Go ahead and save the content of it into a file called: my_key_crt.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

5. Create a Trust Keystore and import the Root certificate into it.

$ keytool -import -trustcacerts -file my_key_root.pem -alias my_key_root -keystore my_key_trust.jks -storepass <store_pass> -keypass <key_pass>

Expected Output:
Certificate already exists in system-wide CA keystore under alias <geotrustglobalca>
Do you still want to add it to your own keystore? [no]: yes
Certificate was added to keystore

6. Generate an Identity Keystore and import Server into it.

$java utils.ImportPrivateKey -keystore my_key_identity.jks -storepass <store_pass> -storetype JKS -keypass <key_pass> -alias server_identity -certfile my_key_crt.pem -keyfile my_key_pk.pem -keyfilepass <pfx_password>

With these instructions, two jks files will be produced:

  • my_key_identity.jks
  • my_key_trust.jks

With both files, the next step is to configure Custom Identity and Custom Trust on WebLogic Server.

Apply a BSU patch manually in Off-line Mode

To apply patch or patches in Off-line mode.

Note that you will need at least the patch-catalog.xml and one patch jar file.

BSU Patch Installation Off-line Mode
Apply patch or patches in Off-line mode
Note: To apply the patch in offline mode refer to the section 8 Using the Command-Line Interface of Using the Command-Line Interface guide available
here -


1. Make sure you have the following files inside Folder WLS_ORACLE_HOME/utils/bsu/cache_dir
- patch-catalog.xml
- XXXX.jar

Note that XXXX is the patch ID, is just a reference name.

2. Apply the patch by running the following command:

> cd WLS_ORACLE_HOME/utils/bsu/

> ./ -prod_dir=WLS_ORACLE_HOME/wlserver_10.3 -patchlist=<Patch_Id> -verbose -install

For example:

> ./ -prod_dir=/Oracle/Middleware/wlserver_10.3 -patchlist=XXXX -verbose -install

After this the patch should be applied successfully.

3. You can view the report of applied patches by running the following command:

> ./ -report -patch_id_mask=<Patch_Id>

For example:

> ./ -report -patch_id_mask=XXXX

4. Restart the server and watch the standard output logs to verify the installation.

5. If you have more patches to apply go to step 1.
6. Repeat the process on each Instance Server including the admin Server.

WebLogic Server: Where to Download the Type 4 JDBC Driver For Microsoft SQL Server.

The Type 4 JDBC driver for Microsoft SQL Server can be downloaded from the following Microsoft Download Center site:

Obtaining the correct Client IP address when a Physical Load Balancer and a Web Server Configured With Proxy Plug-in Are Between The Client And Weblogic

Some Load Balancers like Big-IP have build in interoperability with Weblogic Cluster, this means they know how Weblogic understand a header named 'WL-Proxy-Client-IP' to identify the original client ip.

The problem comes when you have a Web Server configured with weblogic plug-in between the Load Balancer and the back-end weblogic servers - WL-Proxy-Client-IP this is not designed to go to Web server proxy plug-in. The plug-in will not use a WL-Proxy-Client-IP header that came in from the previous hop (which is this case is the Physical Load Balancer but could be anything), in order to prevent IP spoofing, therefore the plug-in won't pass on what Load Balancer has set for it.

So unfortunately under this Architecture the header will be useless.

To get the client IP from Weblogic you need to configure extended log format and create a custom field that gets the appropriate header containing the IP of the client.

On WLS versions prior to 10.3.3 use these instructions:

You can also create user-defined fields for inclusion in an HTTP access log file that uses the extended log format. To create a custom field you identify the field in the ELF log file using the Fields directive and then you create a matching Java class that generates the desired output. You can create a separate Java class for each field, or the Java class can output multiple fields. For a sample of the Java source for such a class, see

Java Class for Creating a Custom ELF Field to

import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;

/* This example outputs the X-Forwarded-For field into a
custom field called MyOriginalClientIPField

public class MyOriginalClientIPField implements CustomELFLogger{
 public void logField(HttpAccountingInfo metrics,
  FormatStringBuffer buff) {

In this case we are using 'X-Forwarded-For' but it could be changed for the header that contains the data you need to use.

Compile the class, jar it, and prepend it to the classpath.

In order to compile and package the class:

1. Navigate to <WLS_HOME>/user_projects/domains/<SOME_DOMAIN>/bin
2. Set up an environment by executing: $ . ./ This will include weblogic.jar into classpath, in order to use any of the libraries included under package weblogic.*
3. Compile the class by copying the content of the code above and naming the file as:

4. Run javac to compile the class.


5. Package the compiled class into a jar file by executing:

$jar cvf0 MyOriginalClientIPField.jar MyOriginalClientIPField.class

Expected output is:

added manifest
adding: MyOriginalClientIPField.class(in = 711) (out= 711)(stored 0%)

6. This will produce a file called:


This way you will be able to get the real client IP when the request is passing through a Load Balancer and a Web server before reaching WLS.

Since 10.3.3 it is possible to configure a specific header that WLS will check when getRemoteAddr is called. That can be set on the WebServer Mbean. In this case, set that to be X-Forwarded-For header coming from Load Balancer as well.

Create a Self Signed Sertificate on WLS 10.3.5 Supporting SHA 256 Algorthim.

1) Set domain to call the keytool


2) Generate the key

$ keytool -genkey -alias selfsignedcert -keyalg RSA -sigalg SHA256withRSA -keypass privatepassword -keystore identity.jks -storepass password -validity 365

What is your first and last name?
What is the name of your organizational unit?
[Unknown]: a
What is the name of your organization?
[Unknown]: e
What is the name of your City or Locality?
[Unknown]: i
What is the name of your State or Province?
[Unknown]: o
What is the two-letter country code for this unit?
[Unknown]: U
Is CN=, OU=a, O=e, L=i, ST=o, C=U correct?
[no]: yes

3) Export the root certificate

$ keytool -export -alias selfsignedcert -sigalg SHA256withRSA -file root.cer -keystore identity.jks
Enter keystore password:
Certificate stored in file <root.cer>

4) Import the root certificate to the trust store

$ keytool -import -alias selfsignedcert -sigalg SHA256withRSA -trustcacerts -file root.cer -keystore trust.jks
Enter keystore password:
Re-enter new password:
Owner: CN=, OU=a, O=e, L=i, ST=o, C=U
Issuer: CN=, OU=a, O=e, L=i, ST=o, C=U
Serial number: 4f17459a
Valid from: Wed Jan 16 15:33:22CLST 2012 until: Thu Jan 15 15:33:22 CLST 2013
Certificate fingerprints:
MD5: 7F:08:FA:DE:CD:D5:C3:D3:83:ED:B8:4F:F2:DA:4E:A1
SHA1: 87:E4:7C:B8:D7:1A:90:53:FE:1B:70:B6:32:22:5B:83:29:81:53:4B
Signature algorithm name: SHA256withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore

5) To check the contents of the keystore

keytool -v -list -keystore identity.jks
Enter keystore password:

***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: selfsignedcert
Creation date: Jan 18, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Owner: CN=example, OU=a, O=e, L=i, ST=o, C=U
Issuer: CN=, OU=a, O=e, L=i, ST=o, C=U
Serial number: 4f17459a
Valid from: Wed Jan 16 15:42:16CLST 2012 until: Thu Jan 15 15:42:16 CLST 2013
Certificate fingerprints:
MD5: 7F:08:FA:DE:CD:D5:C3:D3:83:ED:B8:4F:F2:DA:4E:A1
SHA1: 87:E4:7C:B8:D7:1A:90:53:FE:1B:70:B6:32:22:5B:83:29:81:53:4B
Signature algorithm name: SHA256withRSA
Version: 3


6) In some cases, this parameter is needed in the server start up parameters.


Otherwise, enable it from the Server configuration -> SSL -> Use JSSE checkbox.

Migrating a WebLogic Domain from a 32 to a 64 bit JVM/Architecture

Currently on 32 bit OS which presents a physical constraint when trying to allocate memory.

By limit, a 32 bit OS, will not be able to allocate more than 3 GB on a Linux environment, or 2 GB for Windows environment (not considering Physical Address Extension (PAE) implementation, which can increase the maximum allocatable memory).

When this limit is reached, a migration to a 64 bit architecture is recommended.

Below are the steps on how to install a 64 WebLogic Server version, along with a 64 Bit JVM and then how to migrate the domain to this new environment.

Weblogic Server Version: WebLogic Server Version:
OS: Linux 2.6.18-194.el5 #1 SMP Mon Jan 01 22:10:29 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
JVM:java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Oracle JRockit(R) (build R28.1.1-13-139783-1.6.0_22-20101206-0136-linux-x86_64, compiled mode)

To create migration template:

1. Execute $<WLS_HOME>/wlserver_10.3/common/bin/
2. Create Domain Template.
3. Select Domain to migrate.
4. Enter the name of template and other info. Click next.
5. Using Add Button, Select libraries you want to add under lib folder. copy jdbc data sources you would like to have under config/jdbc folder. If you want to have log4j configuration, copy log4j.xml under domain_root folder.
6. Select data base for the domain and click next.
7. Enter Admin Server Name and port numbers. Click next.
8. Enter username and password. Click next. Select No if you don want to add users/groups/roles
9. Click next until reach button create.

This will create a jar file that is needed for the next action plan.

To install and migrate domain to 64 bit architecture.

1. Install JVM Jrockit R28.1.1.13 on environment. (uncompress zip folder on a known location)
2. Go to JRockit_Home/bin and execute $ java -d64 -jar wls1034_generic.jar
3. When prompt, select JRockit JVM in browse menu, and wait for installation to finish.
4. Go to <WLS_HOME>/wlserver_10.3/common/bin and execute $ ./
5. Select Create a new Weblogic domain
6. Select Base this domain on an existing template and select browse.
7. Select jar file created on previous action plan.
8. Select Name of domain. Maintain in most cases.
9. Select user name and password. Maintain in most cases.
10. Select Jrockit SDK 1.6.0_22 and click next.
11. Confirm all JMS/JDBC/security configuration.
12. On select Optional Configuration, reconfigure if necessary.
13. Check on Configuration summary for all domain configuration.
14. Click on create, to finish up domain import.

Note: Always when installing a 64 bit WLS, it's necessary to install first the 64 JVM and then run the generic installer with the -d64 bit option. If this is not performed, the installation will be the 32 default version.

For more information, please refer:

Change the Log Level of Node Manager.

This is useful to troubleshoot issues related to Node Manager, such as problems starting a Managed Server or reasons a server could be (re)started.

To change the Log Level of Node Manager, you need to edit the file. This is usually located at:


What you need to modify is property:


Information about the appropriate values for this property is available in the Node Manager Documentation at 10.3 WebLogic Documentation (and in further releases) which states:


Severity level of logging used for the Node Manager log. Node Manager uses the same logging levels as WebLogic Server.

Default value: INFO

However, this is incorrect. WLS has its own implementation of LogLevel, but Node Manager uses the standard Log Level from the java.util.logging.Level class. Therefore, the possible values for Node Manager LogLevel, in descending order are:

  • SEVERE (highest value)
  • INFO
  • FINE
  • FINEST (lowest value)

The highest value provides only messages at the severe level. The warning level provides warning messages and severe messages, and so on. Besides those levels, ALL and OFF are also accepted.

For example, if you only want Severe messages to be logged, select SEVERE. If you need the most detailed tracing available, select FINEST.

For more information on what it will log at each level, please read the Java SE API for LoggingLevel.

Sunday Oct 14, 2012 Connection reset; No available router to destination

Sometimes a Weblogic Server will be unreachable, there could be several reasons, the server is hang, down, and thus not responding to a ping, or it could be related to a network issue.

A possible point of failure in the network layer are firewalls.
You should contact your network team if you have following messages:

java weblogic.Admin -adminurl t3:// -username admin -password lockdown PING

Failed to connect to t3:// Destination unreachable; nested exception is: Connection reset; No available router to destination

A possible work around for the ping command is to use the HTTP protocol, instead of the t3 protocol.

To enable this you must configure WebLogic to do HTTP tunneling.

To enable, access the administration console, click servers-> server you want to reach-> protocols -> http -> enable Tunneling.

no restart is necessary.

And then, following command will work:

java weblogic.Admin -adminurl -username igmadmin -password l0ckdown PING

Tuesday Oct 09, 2012

Set up Work Manager Shutdown Trigger in WebLogic Server 10.3.4 Using WLST

WebLogic Server's Work Managers provide a way to control work and allocated threads. You can set different scheduling guidelines for different applications, depending on your requirements.

There is a default self-tuning Work Manager, but you might want to set up a custom work manager in some circumstances: for example,

  • when you want the server to prioritize one application over another
  • when a response time goal is required, or
  • when a minimum thread constraint is needed to avoid deadlock.

The Work Manager Shutdown Trigger is a tool to help with stuck threads in which will do the following:

  1. Shut down the Work Manager.
  2. Move the application to Admin State (not active).
  3. Change the Server instance health state to failed.

Example of a Shutdown Trigger set on the config.xml for your domain:


Understand that any misconfiguration on the Work Manager can lead to poor performance on the server. Any changes must be done and tested before going to production.

How can one create a WorkManagerShutdownTrigger for WLS 10.3.4 using WLST?

You should be able to create a WorkManagerShutdownTrigger using WLST by following these steps:


JMS : Specifying Message Paging Directory on Weblogic server.

Two ways to configure or modify Paging directory, here the examples :

1.- Via config.xml file.


<persistent-store xsi:nil="true"></persistent-store>
<temporary-template-resource xsi:nil="true"></temporary-template-resource>
<temporary-template-name xsi:nil="true"></temporary-template-name>


2 .- Via WLST (Weblogic scripting tool)


Configuring log4j on weblogic server for web applications.

To configure Weblogic server :

1.- Read the following link :
How to Use Log4j with WebLogic Logging Services

Here the step by step :

2.- Go to WL_HOME/server/lib and copy wllog4j.jar to the server CLASSPATH, to do this copy the file into DOMAIN_NAME/lib
3.- Download log4j jar (in my case I had not the file) from , in this case the last available version is log4j-1.2.17.jar, and copy the file into DOMAIN_NAME/lib (As step 2).
4.- In this case I activate log4j using WLST (Weblogic Scripting Tool), as bellow :

4.1 .- As you're using windows, execute a terminal window and go to DOMAIN_NAME/bin and run the file setDomainEnv.cmd (this file will set the environment to run java).
4.2 .- Execute the following comands :

C:\>java weblogic.WLST
wls:/offline> connect('username','password')
wls:/mydomain/serverConfig> edit()
wls:/mydomain/edit> startEdit()
wls:/mydomain/edit !> cd("Servers/$YOUR_SERVER_NAME/Log/$YOUR_SERVER_NAME";)
wls:/mydomain/edit/Servers/myserver/Log/myserver !> cmo.setLog4jLoggingEnabled(true)
wls:/mydomain/edit/Servers/myserver/Log/myserver !> save()
wls:/mydomain/edit/Servers/myserver/Log/myserver !> activate()

you can use ls() to list the objects under the WLS directory

this will activate log4j to use it with WLS.

Configuring WebLogic Logging Services

To configure applications :

1. Create a file as bellow

log4j.rootLogger=INFO, R
log4j.appender.R.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSSS} %p %t %c – %m%n

2. Copy the file to /WEB-INF/classes directory. of your application.

3.- implement also the last action provided to activate log4j on WLS

How to set up secure cookie on weblogic server

WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:

<WebServer Name="myserver" AuthCookieEnabled="true"/>

Setting AuthCookieEnabled to true, which is the default setting, causes the WebLogic Server instance to send a new secure cookie, _WL_AUTHCOOKIE_JSESSIONID, to the browser when authenticating via an HTTPS connection. Once the secure cookie is set, the session is allowed to access other security-constrained HTTPS resources only if the cookie is sent from the browser.

Thus, WebLogic Server uses two cookies: the JSESSIONID cookie and the _WL_AUTHCOOKIE_JSESSIONID cookie. By default, the JSESSIONID cookie is never secure, but the _WL_AUTHCOOKIE_JSESSIONID cookie is always secure. A secure cookie is only sent when an encrypted communication channel is in use. Assuming a standard HTTPS login (HTTPS is an encrypted HTTP connection), your browser gets both cookies.

For subsequent HTTP access, you are considered authenticated if you have a valid JSESSIONID cookie, but for HTTPS access, you must have both cookies to be considered authenticated. If you only have the JSESSIONID cookie, you must re-authenticate.

To configure on Admin Console :

  1. Log into WebLogic Admin Console.
  2. Under Domain Structure, press click on <domainname>
  3. Select the "Web Applications" tab
  4. Select "Lock and Edit" in change center.
  5. Click on  "Auth Cookie Enabled" checkbox.
  6. Restart to confirm changes.
  7. Test an application and view the cookie which got stored as "JSESSIONID"

To Configure the Web application's weblogic-application.xml file:

  1. Run the following to extract the file from the web application's weblogic-application.xml: $PATH_JDK_HOME\binjar -xvf easy-web-examples.ear META-INF/weblogic-application.xml
  2. Add <cookie-secure>true</cookie-secure> between <session-descriptor> </session-descriptor> to the weblogic-application.xml.
  3. Run the following to repackage the file to the application: $PATH_JDK_HOME\bin\jar -uvf easy-web-examples.ear META-INF/weblogic-application.xml
  4. Deploy the application into WebLogic

For further information, please read the documentation on "Using Secure Cookies to Prevent Session Stealing " :

Time Zone on WebLogic Server

In order to configure the time zone with WebLogic Server, use the following JVM startup command:


For example, in the java arguments in the admin console at Environments -> Servers -> Servername -> - Server Start tab, configure the startup settings that Node Manager will use to start the particular server. For example:


There are many different time zones, each with its own code. For a complete list please refer to :

For testing, you can run the following code on WLS with a JSP, servlet, or deploying the class:

import java.util.Calendar;
import java.util.TimeZone;

public class TestTimeZone {

 public static void main(String[] args) {

   Calendar calendar = Calendar.getInstance();

   TimeZone timeZone = calendar.getTimeZone();

   System.out.println(" your Current TimeZone is : " + timeZone.getDisplayName());
   System.out.println(" Time Zone id : "+ timeZone.getID());


Rotating WebLogic Server logs to avoid large files using WLST.

By default, when WebLogic Server instances are started in development mode, the server automatically renames (rotates) its local server log file as SERVER_NAME.log.n.  For the remainder of the server session, log messages accumulate in SERVER_NAME.log until the file grows to a size of 500 kilobytes.

Each time the server log file reaches this size, the server renames the log file and creates a new SERVER_NAME.log to store new messages. By default, the rotated log files are numbered in order of creation filenamennnnn, where filename is the name configured for the log file. You can configure a server instance to include a time and date stamp in the file name of rotated log files; for example, server-name-%yyyy%-%mm%-%dd%-%hh%-%mm%.log.

By default, when server instances are started in production mode, the server rotates its server log file whenever the file grows to 5000 kilobytes in size. It does not rotate the local server log file when the server is started. For more information about changing the mode in which a server starts, see Change to production mode in the Administration Console Online Help.

You can change these default settings for log file rotation. For example, you can change the file size at which the server rotates the log file or you can configure a server to rotate log files based on a time interval. You can also specify the maximum number of rotated files that can accumulate. After the number of log files reaches this number, subsequent file rotations delete the oldest log file and create a new log file with the latest suffix.

 Note: WebLogic Server sets a threshold size limit of 500 MB before it forces a hard rotation to prevent excessive log file growth.

To Rotate via WLST :

#invoke WLST
C:\>java weblogic.WLST

#connect WLST to an Administration Servera
wls:/offline> connect('username','password')

#navigate to the ServerRuntime MBean hierarchy
wls:/mydomain/serverConfig> serverRuntime()

#navigate to the server LogRuntimeMBean
wls:/mydomain/serverRuntime> cd('LogRuntime/myserver')
wls:/mydomain/serverRuntime/LogRuntime/myserver> ls()
-r-- Name myserver
-r-- Type LogRuntime

-r-x forceLogRotation java.lang.Void :

#force the immediate rotation of the server log file
wls:/mydomain/serverRuntime/LogRuntime/myserver> cmo.forceLogRotation()

The server immediately rotates the file and prints the following message:

<Mar 2, 2012 3:23:01 PM EST> <Info> <Log Management> <BEA-170017> <The log file C:\diablodomain\servers\myserver\logs\myserver.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms like Windows.>

<Mar 2, 2012 3:23:01 PM EST> <Info> <Log Management> <BEA-170018> <The log file has been rotated to C:\diablodomain\servers\myserver\logs\myserver.log00001. Log messages will continue to be logged in C:\diablodomain\servers\myserver\logs\myserver.log.>

To specify the Location of the archived Log Files

The following command specifies the directory location for the archived log files using the -Dweblogic.log.LogFileRotationDir Java startup option:

java -Dweblogic.log.LogFileRotationDir=c:\foo weblogic.Server

For more information read the following documentation ;

Using the WebLogic Scripting Tool

Configuring WebLogic Logging Services


Antonio De Juan Image

I was formerly a Senior Technical Support Engineer in the Middleware Application Server Team. I worked supporting Weblogic Server, Java EE, Jrockit, Coherence among other Oracle products.
You can find my new blog at :
Oracle WebLogic


« December 2016