How To Ensure No ResultSet/Connection/Statement Leaks Exist in Your JDBC Code

The classes shown below require explicit closure to release resources established at the database level. Connection objects leave database sessions open, and Statement and ResultSet objects leave cursors open at the database level. The corresponding JDBC API's are listed below.


In order to release resources associated with these objects the method close() must be called once the program has finished working with the objects. Below are some common problems encountered when closing resources and a simple utility class for closing these resources.

Dead Connection Detection (DCD) Explained


Dead Connection Detection (DCD) is a feature of SQL*Net 2.1 and later, includingOracle Net8 and Oracle NET. DCD detects when a partner in a SQL*Net V2 client/serveror server/server connection has terminated unexpectedly, and flags the dead sessionso PMON can release the resources associated with it. DCD is intended primarily for environments in which clients power down their
systems without disconnecting from their Oracle sessions, a problemcharacteristic of networks with PC clients.

DCD is initiated on the server when a connection is established. At this time SQL*Net reads the SQL*Net parameter files and sets a timer to generate an alarm. The timer interval is set by providing a non-zero value in minutes for the SQLNET.EXPIRE_TIME parameter in the sqlnet.ora file.

When the timer expires, SQL*Net on the server sends a "probe" packet to the client. (In the case of a database link, the destination of the linkconstitutes the server side of the connection.) The probe is essentially an empty SQL*Net packet and does not represent any form of SQL*Net level data,

but it creates data traffic on the underlying protocol. If the client end of the connection is still active, the probe is discarded, and the timer mechanism is reset. If the client has terminated abnormally,

the server will receive an error from the send call issued for the probe, and SQL*Net on the server will signal the operating system to release the connection's resources.

On Unix servers, the sqlnet.ora file must be in either $TNS_ADMIN  or  $ORACLE_HOME/network/admin. Neither /etc nor /var/opt/oracle alone is valid. It should be also be noted that in SQL*Net 2.1.x, an active orphan process (one processing a query, for example) will not be killed until the query completes. In SQL*Net 2.2, orphaned resources will be released regardless of activity. This is a server feature only. The client may be running any supported SQL *Net V2 release. 

Understanding Inactive Sessions From JDBC Connection Pool in Oracle Weblogic Server

JDBC connections are established with the database server when there is an application connection request coming from the client. The JDBC connection pool is intended to have a farm of open JDBC connections to the database which can be borrowed by the application. Performance-wise, this is more efficient, since it saves opening and closing a JDBC connection each time. However, this means that a connection can be idle for quite a long time when there is little activity in the system. Most connections will spend most of their time either sitting in the connection pool waiting for a Java thread to open them, or waiting on the Java thread to do something with the data, or waiting on the network to transfer data between the machines. That means that there will be a reasonable number of connections to the database where the STATUS in V$SESSION is "INACTIVE" at any given point in time. That is perfectly normal.
However, it is important to verify that there is no steady increase in the number of open connections, pointing to a leak of connections that prevent these from being reused and cause the maximum number of connections to be reached. To avoid this:

  • Connections used from the JDBC pool need to be closed after usage by the application code. If close() is not called, connections are not freed and not available for reuse. Please refer to: How To Ensure No ResultSet/Connection/Statement Leaks Exist in Your JDBC Code
  • Connection pools should be configured with timeout properties. Depending on the connection pool, there are particular properties for this. For example, for Oracle Universal Connection Pool (UCP), you can refer to: Controlling Stale Connections
  • There is no mechanism in the Connection pool to determine whether the JDBC connection to the database has been dropped. So the JDBC connection in the pool still seems to be valid until the application borrows it, and then finds out that the connection is invalid as it has been dropped.
  • For this, the connection pool has an option to validate the connection before passing it to the application. On this, for example for UCP, please refer to: Validating connections

JDBC Weblogic server Issue

WebLogic Server Crashes because of native JDBC driver libraries

As type-2 JDBC drivers use native code, problems in these drivers may lead to a crash of the JVM and WebLogic Server. If your server crashes, check information provided in the Binary Core File Analysis . This information will help to track down the native library that causes the crash and provides tips on how to solve the problem.

WebLogic Server or application hangs in JDBC driver methods or functions

A JDBC connection uses an execute thread from WebLogic Server to perform its work. This means that a hanging request to a database blocks one thread in WebLogic Server. Problems with the JDBC connection or the database infrastructure can lead to a hang in WebLogic Server or the application. Information on analyzing this kind of problem is included in the JDBC Causes WebLogic Server Hang Support .

A memory leak of JDBC objects leads to an OutOfMemoryError or growing process size

JDBC objects used by connections from the JDBC connection pool or in application code, that connect directly to a database, are part of the heap or native memory of the process. If these objects are not closed and freed correctly, a memory leak is the consequence, which causes increased heap usage or growing process size, and finally will lead to an OutOfMemoryErrorafter the JVM or the operating system cannot provide free memory anymore.If you see OutOfMemoryErrorsin your system and suspect JDBC objects to be the cause, please check Oracle WebLogic Server Core Server/JVM/Memory Issues Support Patterns - Investigating Out of Memory/Memory Leak Problems .

Oracle Weblogic JDBC General Issue Topics

Troubleshooting JDBC problems by debugging or tracing JDBC

JDBC debugging and tracing sometimes is key in order to find out what is going on and analyze the SQL statements that actually are sent to the database. However JDBC is a multi-layered subsystem, of which only parts are inside WebLogic Server. Debugging and tracing of the JDBC driver layer is highly driver-dependent. Information regarding debug and trace flags for the drivers are available from the driver vendors.
Once you have narrowed the problem down to a specific area, you can activate WebLogic Server’s debugging features to track down the specific problem within the application. Debugging can be activated by setting the appropriate ServerDebug configuration attribute to true. See Debugging JDBC Data Sources

  • DebugJDBCConn (scope weblogic.jdbc.connection) will enable tracing of all connection reserve and release operations in data sources as well as all application requests to get or close connections.
  • DebugJDBCSQL (scope weblogic.jdbc.sql) will print information about all JDBC methods invoked, including their arguments and return values, and thrown exceptions.
  • DebugJDBCDriverLogging (scope weblogic.jdbc.driverlogging) will enable JDBC driver level logging. Note that to get driver level tracing for Oracle, you need to use ojdbc14_g.jar instead of ojdbc14.jar. Note that for this debug scope, it can be turned on once via the command line or configuration when the server is booted but cannot be turned on or off dynamically (due to the DriverManager interface).
These debug flags and tracing can be very verbose, so consider very carefully where you turn on those flags. They will create a lot of output and also possibly have a slight performance impact on your system. They should not be turned on in production systems.

How to tune JDBC connection pools for production environments?

Configuration of JDBC connection pools for production systems is a critical and important task to ensure stability and performance. Some general recommendations may help as a starting point for administrators:

  • Set InitialCapacity = MaxCapacity: This will ensure that all connections are opened during WebLogic Server startup. As creation of a physical database connection is very expensive, all needed connections should be opened immediately and kept open.  Before doing so, first insure that the physical memory of the database can handle all connections as they could easily add up in memory and lead to swaps.
  • Disable shrinking by setting ShrinkingEnabledto false: As mentioned above, creation of physical database connections is expensive, so connections should be established once and kept during the complete lifetime of the WebLogic Server instance.
  • Turn off refresh functionality if it is not needed: 
  • Set TestConnectionsOnReserveto true. This will ensure that connections are tested before they go to the application and are reopened if needed.
  • Set the number of connections in the JDBC pool equal to the number of execute threads that use the connections. This helps to avoid ResourceExceptions.

JDBC Error Causes in WebLogic Server and troubleshoot

Even a transaction timeout will not kill or timeout any action that is done by the resources that are enlisted in this transaction. The actions will run as long as they take, without interruption. A transaction timeout will set a flag on the transaction that will mark it as rollback only, so that any subsequent request to commit this transaction will fail with a TimedOutException or RollbackException. However, as mentioned above, the long running JDBC calls can lead to blocked WebLogic Server execute threads, which can finally lead to a hanging instance, if all threads are blocked and no execute thread remains available for handling incoming requests.

More recent WebLogic Server versions have a health check functionality that regularly checks if a thread does not react for a certain period of time (the default is 600 seconds). If this happens, an error message is printed to your log file similar to following:

The time interval for the health check functionality is configurable. Please check the StuckThreadMaxTime property in the <Server> tag of your config.xml file or the "Detecting stuck threads" section in the WebLogic Server administration console help

The following are some different possible reasons that can cause JDBC calls to lead to a hanging WebLogic Server instance:

WebLogic Server : Binary Core File Analysis

Problem Description

An application gets a binary core file produced when the WebLogic Server process terminates due to some invalid native core (machine specific code). A server crash, JVM crash, machine crash, or HotSpot error may also be associated with this occurrence. This article will describe what steps are needed to gather information from a core file on various platforms.

Problem Troubleshooting

Please note that not all of the following items would need to be done. Some issues can be solved by only following a few of the items.

Troubleshooting Steps

Why does the problem occur?

In order to determine the cause of such an error you need to determine all potential sources of native code used by the WebLogic Server process. The places to focus on are:
  1. The WebLogic Server performance pack. The WebLogic Server performance pack is native code and when enabled could potentially produce such an error. Disable this feature to determine if that is the cause. You can do this via the console or via the command line. Using the console look under the Server tab by setting NativeIOEnabled to false. See the documentation section Enabling Performance Packs to get the exact sequence of steps under the Server tab in the console. The steps are:
    1. Start the Administration Server if it is not already running.
    2. Access the Administration Console for the domain.
    3. Expand the Servers node in the left pane to display the servers configured in your domain.
    4. Click the name of the server instance that you want to configure.
    5. Select the Configuration --> Tuning tab.
    6. If the Enable Native IO check box is selected, please deselect it in the check box so it is now *not* enabled.
    7. Click Apply.
    8. Restart the server.

Investigating ORA-01000: maximum open cursors exceeded WebLogic Server

Problem Description

Oracle uses the OPEN_CURSORS parameter to specify the maximum number of open cursors a session can have at once. When this number is exceeded, Oracle reports an ORA-01000 error. When this error is propagated to WebLogic Server, a SQLException is thrown.
java.sql.SQLException: ORA-01000: maximum open cursors exceeded
This pattern discusses possible causes and solutions of this error when using WebLogic Server.

Problem Troubleshooting

Please note that not all of the following items would need to be done. Some issues can be solved by only following a few of the items.

Weblogic JDBC issue : Too Many Open Cursors in the Oracle database

If the configured amount of allowed open cursors in an Oracle database is exceeded, the following error message will be thrown:

java.sql.SQLException: ORA-01000: maximum open cursors exceeded
This can be due to the following possible causes:

  • Incorrect configuration of the JDBC pool regarding the prepared statement cache. Every prepared statement will use one open cursor in the Oracle database. The statement cache holds prepared statements on a connection basis. This means that the Oracle database will use up to (StatementCacheSize)x(MaxCapacity)open cursors for every configured pool. As open cursors will be used for other objects also (e.g., stored procedures or result sets), the number of open cursors needs to be configured high enough to hold all the statements in the statement cache. The setting for OPEN_CURSORS is per session/connection.

    For additional information on statement cache configuration, please see Monitoring JDBC Resources

getVendorConnection()is called and physical connection is automatically refreshed after each usage by the application (when RemoveInfectedConnections="true")

As this means that connection pooling loses its effect, i.e., every connection is closed and reopened after each usage, please consider carefully if the application code changes or destroys something on the physical connection that makes such a reopen necessary. If and only if this is not the case, set the property RemoveInfectedConnectionsto false.

More more details :

Investigating Weblogic JDBC Issues : Datasource/Pooling

ResourceException during JDBCDataSource.getConnection() (weblogic.common.ResourceException: No resources available)

ResourceExceptionsare thrown when a getConnection()request via a DataSourceto a JDBC connection pool cannot be satisfied because either no connection in the pool or no thread is available to handle the connection request. Cause of the missing resource could be either one of:

  • Connection leak in the application.
    Connections used from the JDBC pool need to be closed after usage by the application code. If close() is not called, connections are not freed and not available for reuse. A possible symptom for a connection leak for Oracle JDBC connection pools can be an error message:
    ORA-00020 - maximum number of processes (%s) exceeded
    Enabling WLS JDBC trace logging is a good way to identify potential leaks. Messages such as the following get logged when the WebLogic pool has been watching its connections in use, and this connection is currently reserved, but has not been used at all for the inactive-connection-timeout period.
    <Warning><Common><BEA-000620><Forcibly releasing inactive resource "weblogic.jdbc.common.internal.ConnectionEnv" back in the pool "mypool"
    This typically means the application leaked the connection by losing the reference to the connection without/before closing it. The WebLogic logging will include a full stacktrace of where the connection was reserved. This information should help in reviewing how this connection was managed (lost, missed or unused) without closing.

WebLogic Server : Investigating JDBC Issues

The following topics will be covered in this blog.

  • JDBC Datasource/Pooling Issues
    Weblogic Server obtains JDBC connections from a Datasource. Each configured datasource contains a pool of database connections. Configuring it correctly ensures performance and stability of applications and the server itself. Some misconfiguration could lead to many problems such as, but not limited to:
    • weblogic.jdbc.extensions.PoolLimitSQLException
    • weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool
    • Leaks caused by incorrect management of connections in application code
    • Poor performance of the DBMS or the network, so that connection requests to the underlying database lead to very long startup or communication times for the WebLogic Server
    • Errors or java exceptions during JDBC connectivity setup
    • Connection refresh/reconnect problems after the database was down

WebLogic Server JDBC Profiling Options

Connection Usage

            Collect information about threads currently using connections from the pool
             Data Collected:
            * PoolName - name of the data source to which this connection belongs
            * ID - connection ID
            * User - stack trace of the thread using the connection
            * Timestamp - time stamp showing when the connection was given to the thread


  ####<DemoDataSource1 > <WEBLOGIC.JDBC.CONN.USAGE> <Wed Apr 23 07:39:02 EST 2014> <java.lang.Exception
            at weblogic.jdbc.common.internal.ConnectionEnv.setup(
            at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(
            at weblogic.jdbc.common.internal.ConnectionPool.reserve(
            at weblogic.jdbc.common.internal.ConnectionPool.reserve(


How To Migrate Oracle iPlanet Web Server Weblogic Proxy Plugin Configuration To Oracle HTTP Server 11g

This document is provided as a guideline for migrating the Weblogic Proxy Plugin configuration from Oracle iPlanet Web Server (iWS), 6.1.x and 7.0.x, to Oracle HTTP Server 11g (OHS). 

iPlanet 6.1.x and 7.0.x Configuration

The configuration for the Weblogic Proxy Plugin is contained in two files within iWS.

1] The plugin is loaded in the Web Server magnus.conf file (/<Server_Root>/<instance>/config/magnus.conf).
Init fn="load-modules" shlib="/<path_to>/"
2] Requests can be processed in two ways in the obj.conf file (/<Server_Root>/<instance>/config/obj.conf), either by URL or by MIME type. Both the PathTrim and PathPrepend directives are optional and may not be present.
Example proxy by URL:
<Object ppath="*/weblogic/*">>
Service fn=wl-proxy WebLogicPort=1234 PathTrim="/weblogic"
Example proxy by MIME type:
Service method="(GET|HEAD|POST|PUT)" type=text/jsp fn=wl-proxy WebLogicPort=1234 PathPrepend=/jspfiles

Note - with iWS 7.0 the obj.conf file may be prepended with the name of the Virtual Server - <vs>-obj.conf. The correct obj.conf file can be found in the <object-file> tag of the server.xml file for each Virtual Server.

OHS 11g Configuration

The configuration for OHS should be in the directory $ORACLE_INSTANCE/config/OHS/ohs1 for an initial install. The instance name, ohs1, may be different if there are multiple instances installed.

OHS installs the Weblogic module by default. The main OHS configuration file, httpd.conf, should already have an entry to include the configuration file for the module:
# Include the configuration files needed for mod_weblogic
include "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/mod_wl_ohs.conf"
The mod_wl_ohs.conf file should already exist, and will contain commented sample entries, but will have nothing actually configured initially.

The documentation for the Weblogic module provides clear details on how to configure it.

Following the configuration of the Weblogic module, the URL example from the iWS configuration above would be:
<IfModule weblogic_module>

<Location /weblogic>
SetHandler weblogic-handler
WeblogicPort 1234
PathTrim /weblogic

The MIME type example would be:

<IfModule weblogic_module>

WeblogicPort 1234
MatchExpression *.jsp
PathPrepend /jspfiles


How To Migrate Oracle iPlanet Web Server Virtual Server Settings To Oracle HTTP Server 11g

The iPlanet logo
The iPlanet logo (Photo credit: Wikipedia)

This document is provided as a guideline for migrating Virtual Server settings from Oracle iPlanet Web Server (iWS) to Oracle HTTP Server 11g (OHS).

 iPlanet Web Server 7.0.x Configuration
 iWS configuration always contains a least one single default Virtual Server.  A Virtual Server settings can be found in the following ways,
A] The Admin CLI (wadm)
 The Virtual Server properties can be found by running the following wadm command:
/<server_root>/bin/wadm get-virtual-server-prop --user=<admin_user> --host=<serverhost> --port=<port> --ssl=true --config=<config> --vs=<vs>

For example:
#/opt/iplanet/bin wadm get-virtual-server-prop --user=admin --host=localhost --port=8989 --ssl=true --config=config1 --vs=virtual1
Please enter admin-user-password>

In order to get a list of all Configurations and Virtual Servers use the following wadm command: 
# /opt/iplanet/bin/wadm list-configs --user=admin --host=localhost --port=8989 --ssl=true
Please enter admin-user-password>

# /opt/iplanet/bin/wadm list-virtual-servers --user=admin --host=localhost --port=8989 --ssl=true --config=config1
Please enter admin-user-password>

2] You can examine the server.xml file directly, each Virtual Server is defined inside a block of <virtual-server></virtual-server> xml.

iPlanet Web Server 6.1.x Configuration
With iWS 6.1 the Virtual server configuration is stored directly in the server.xml. As it possible to have multiple Virtual Server Classes make sure the file is checked carefully.
<VS id="" connections="ls1" mime="mime1" aclids="acl1" urlhosts="">
            <PROPERTY name="docroot" value="/opt/iplanet/docs"/>
            <USERDB id="default"/>
                <WEBAPP uri="/search" path="/opt/iplanet/bin/https/webapps/search"/>
OHS 11g Configuration
OHS uses the standard Apache Virtual Host configuration.  
Virtual Server configurations are referred to as "Virtual Hosts" with OHS. By default OHS does not require a virtual host configuration to work as it will use the configuration wide settings.

1] To configure a Virtual Host edit the httpd.conf at a suitable location. Alternatively create a separate file and load it using an "Include" directive.  It is worth noting that the SSLrelated virtual hosts are usually placed within the ssl.conf file.
 An example of a name based Virtual Host.
NameVirtualHost *:80

<VirtualHost *:80>
    DocumentRoot "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/htdocs_virtual1"
An simple IP based Virtual Host.
DocumentRoot ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/htdocs_virtual2"
2] Restart ohs
# opmnctl restartproc process-type=OHS

Defining WebLogic Server Terms

Weblogic Terminology


The basic administrative unit of a Weblogic Server Installation is a Domain. A logically related group of Weblogic server resources that managed as a unit.


A server is a instance of  weblogic.Server executing in a JVM. A server runs on a designated Machine(node)and  has dedicated amount of RAM.


Machine is a computer that hosts one or more Weblogic Sever.

Administration Server:

An Administration Server is the central point of control for a domain. It Stores the configuration information and logs for a domain and runs the Weblogic administration console.

Managed Server:

A managed server is any server in a domain that is not a admin server. It contacts the admin server for configuration information and runs business application.


A cluster is a logical group of Weblogic servers. It provide automatic fault tolerance, Load-balancing and High availability.

Node Manager:

It's a daemon which start/stop/restart servers in a domain remotely.

Weblogic Interview Questions and Answers

Gone through lots of Weblogic Administration  Interview in this year with companies like Oracle, Cognizant, Tech Mahindra, Vodafone, IBM etc. I'm trying to post here some common weblogic interview questions with Answers. Please read and post/ask any questions & Answers you have come across recently.

(1) It has got app container (and obviously web container) inside it and thus EJB can be deployed in it 'Vs' (1)It has got web container inside it and it acts as front end where JSPs are deployed on it.
(2) Main business logic is deployed on the app server   'Vs' (2) It is used as proxy in front of app server for load balancing.
(3) Examples of commonly used app servers in market are Weblogic, Websphere, JBoss  'Vs' (3) Examples of commonly used web servers are apache, IIS, Iplanet.

3.High availibility

It is the mechanism by which session & session related data is transferred to other cluster members.

Q) Types of session replication:
Client first connects to a server and that server becomes the primary server. The primary server then copies the data on to a server and the other cluster members  fetches the session data from that server and also the other server keeps their session data on to that server and the primary server fetches that session data from  that server, and,  thus all the servers keep updated with the latest session data.
NOTE: This type of session replication is internally used by weblogic if we do not define below mentioned strategies.

Session data is stored in the memory (cache). After restart the session data get lost.

Session data gets stored in the user's browser.

This is File based session replication wherein the session data gets stored in an xml file.

The session data is stored in DB (i.e persistent store).

NOTE:  2,3,4,5 are defined inside weblogic.xml inside <session-descriptor> tag.

Commonly known error:
ERROR: serializable Exception
REASON (can be):
A non serializable object inside HTTP session which is not replicating to other cluster members.

NoClassDefFoundError When Deploying JSF Application Using Commons-Logging And Log4j to Oracle WebLogic


When a single JSF page application with a backing bean that contains an apache commons logging statement using Log4j.jar as the logging provider is deployed,Weblogic always throws an exception.
Including commons-logging.jar and log4j.jar on the classpath causes the exception.

com.sun.faces.mgbean.ManagedBeanCreationException: Cant instantiate class: view.backing.Hello.
at com.sun.faces.mgbean.BeanBuilder.newBeanInstance(
at com.sun.faces.mgbean.BeanManager.createAndPush(
at com.sun.faces.mgbean.BeanManager.create(
at com.sun.faces.el.ManagedBeanELResolver.getValue(
Truncated. see log file for complete stacktrace
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger) (Caused by
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger))

at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
at org.apache.commons.logging.LogFactory.getLog(
at view.backing.Hello.<init>(
Truncated. see log file for complete stacktrace
org.apache.commons.logging.LogConfigurationException: No suitable Log constructor
[Ljava.lang.Class;@16b7343 for org.apache.commons.logging.impl.Log4JLogger (Caused by
java.lang.NoClassDefFoundError: org/apache/log4j/Logger)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(
at org.apache.commons.logging.LogFactory.getLog(
Truncated. see log file for complete stacktrace
java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(
at java.lang.Class.getConstructor0(
at java.lang.Class.getConstructor(
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(
Truncated. see log file for complete stacktrace
java.lang.ClassNotFoundException: org.apache.log4j.Logger
at Method)
at java.lang.ClassLoader.loadClass(
at sun.misc.Launcher$AppClassLoader.loadClass(
Truncated. see log file for complete stacktrace


The webapp classes are not overriding the system classes.


Add the parameter "prefer-web-inf-classes" to your web-app's weblogic.xml:


To create a weblogic.xml descriptor:
  1. Right click your ViewController Project in JDeveloper, select New.
  2. Go to Deployment Descriptors > WebLogic Deployment Descriptors > Click OK.
  3. Choose weblogic.xml and follow through.

Deploying Application on Oracle Weblogic 10.3.x throws java.lang.NoClassDefFoundError: org/apache/log4j/Priority


Deploying an ear application onto a WLS 10.3.x domain throws the following error:
Web application: "DataExtractWeb2".
java.lang.NoClassDefFoundError: org/apache/log4j/Priority
  at org.sagph.dataextract.web.DxWebStartup.loadProperties(
  at org.sagph.dataextract.web.DxWebStartup.init(
  at weblogic.servlet.internal.StubSecurityHelper$
Caused By: java.lang.NoClassDefFoundError: org/apache/log4j/Priority
  at org.sagph.dataextract.web.DxWebStartup.loadProperties(
  at org.sagph.dataextract.web.DxWebStartup.init(
  at weblogic.servlet.internal.StubSecurityHelper$
The same application works fine on WLS 10MP1 but it is not working on WLS 10.3.x.


In WLS versions prior to 10.3.0, the log4j.jar is present in the class path and it gets loaded automatically at the time of server start. But this is not the case for WLS 10.3.0 and later releases. In WLS 10.3.0 and higher, the log4j file is no longer automatically loaded. In this case, the customer application had a dependency on log4j, and so it failed when log4j.jar was no longer automatically loaded with the WLS installation.


There are two ways to resolve, as below:

The first solution is to load the log4j jar file on startup. To accomplish this, change the value of load-on-startup tag to 1 from -1in web.xml for the servlet code that is referring to log4j. For example, in web.xml, make this change:

The second solution is to place the jar file in the APP-INF/lib directory of the ear file, i.e., <ear_file>/APP-INF/lib. The jar file will be loaded with the ear file and provide the jar file when the application needs it. After adding the jar file to the ear, redeploy the application and restart.

Oracle Weblogic: Deployment of Applications Failing with java.lang.ClassCastException

Sometime weblogic throws ClassCastException while application deployment. Below is one of the scenario and steps how go through with this issue.


WebLogic Server deployment of applications using stax classes is failing with a ClassCastException:

java.lang.ClassCastException: com.ctc.wstx.stax.WstxInputFactory


This issue was because the customer application uses a different stax jar file version as compared to jar file used by system class loader. Since both have "com.ctc.wstx.stax.WstxInputFactory" as a member, the class is loaded by the system class loader rather than the application class loader, and that is incompatible with its use by the application code.


To resolve this issue, use the FilteringClassLoader in weblogic.xml (or) weblogic-application.xml descriptor files to load particular classes/packages (in this case, "com.ctc.wstx.stax.*") from the application jar file instead of the system classloader. Below is a snippet of weblogic-application.xml file which has FilteringClassLoader implementation (<prefer-application-packages>) for reference.
UTF-8" ?>
<wls:weblogic-application xmlns:wls=""


JVM crash: java.lang.OutOfMemoryError

The JVM crashed. The head of the fatal error log file shows the error message in bold below:
# A fatal error has been detected by the Java Runtime Environment:
# java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
Internal Error (allocation.cpp:166), pid=14032, tid=22
Error: ChunkPool::allocate
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) Server VM (19.0-b09 mixed mode solaris-x86 )
# If you would like to submit a bug report, please visit:


The malloc() call in the ChunkPool::allocate() function failed to allocate new memory, causing the JVM process to exit with the error "ChunkPool:allocate".

In other words, the HotSpot JVM ran out of native memory in the space reserved in native heap (C-heap) for compiling java methods.