How to use DataSources in a Web Application on Oracle OAS10g

There are many how-to documents on using DataSources in web applications. I’m adding yet another, mainly because I want one in a location that I can remember when I need to point someone at it. Additionally, there aren’t a ton of documents on how to set all this up for OAS10g application server.

This document will outline the proper way to reference a DataSource on OAS and how to set up the application-specific configuration file with a default JNDI mapping for the logical DataSource.
Continue reading How to use DataSources in a Web Application on Oracle OAS10g

Working around dependency conflicts

One of my teammates ran head on into some dependency conflicts recently.  The application in question must use 2 sets of APIs from 2 vendors.  One for our content management system provider and the other from our search platform provider.

Unfortunately, the 2 APIs have conflicting dependencies and to make matters worse, the Content Management vendor hides these dependencies by wrapping all of their dependencies into a single jar file. (thirdparty-combined.jar)   Having all the dependencies wrapped inside a single jar prevents me from being able to simply swap out the conflicting version.

The problem comes up when we put both commons-httpclient-3.0.jar and this thirdparty-combined.jar (which contains commons-httpclient-2.0) into the WEB-INF/lib directory of our application.  Java does not give us a method for controlling the priority of jars in WEB-INF/lib, so we are at the mercy of the app server which for some reason behaves differently on our local desktop, dev, and test tiers.

The simple solution would be to resolve the dependency by including only commons-httpclient-3.0.jar.¬† Unfortunately, thanks to the vendor’s decision to jam all of their dependencies into a single jar, we don’t have the option of removing the conflicting version.

To work around the problem, we had to ensure that commons-httpclient-3.0.jar would be loaded by a higher-level classloader (or parent classloader) to the web app’s classloader.¬† We accomplished this by packaging the app as an EAR file and adding commons-httpclient-3.0.jar to the ear file.¬† We then added a reference to the ear file’s copy of commons-httpclient-3.0.jar to the webapp’s manifest classpath in the war files MANIFEST.MF file.

On our app servers, the war manifest classpath is accessed by the classloader that is parent to the loader for WEB-INF/lib.  This ensures that the desired version of the library is loaded first.

I still need to do some research to see if I can find a cleaner solution, but this will allow us to meet our release deadline.

Things I don’t like about the way we resolved this include:

  • Having to muck with the Manifest Classpath for the webapp
  • Different app servers behave differently, so this may not work on another app server, or even on the next version of the app server

Ideally, I would like to find a way to have this loaded by the ear file’s classloader which can generally be expected to be the parent classloader for the included war files.¬† I just haven’t had time to mess about with it further.

Can you find the connection leak?

I did a short code review with a developer who couldn’t understand why some code was leaking connections. As far as the developer could tell, he was closing out all of the database objects correctly.
Consider the following code and see if you can find the connection leak:

public static String getNiDNAString(String lookup, String value)
    throws SQLException {
        // Create the initial context. No JNDI properties are to be supplied
        InitialContext initialContext = new InitialContext();
        PreparedStatement psSelect = null;
        ResultSet rsSelect = null;
        DataSource dataSource = (DataSource) initialContext.lookup("DS-NameHere");

    // Execute the query and get the results back from the handler
        String result="";
            psSelect = dataSource.getConnection().prepareStatement(
                "SELECT 42 from dual where 1=?"; // Query was changed
                psSelect.setString(1, "1");
            if((rsSelect = psSelect.executeQuery()).next())
        catch(SQLException sqlexception)
            throw sqlexception;
            closeObjects(rsSelect, psSelect, dataSource.getConnection());
        return result;

public static void closeObjects(ResultSet rs, Statement s, Connection c)

    // Assume this implementation correctly closes all objects

The problem, of course lies in this call:

closeObjects(rsSelect, psSelect, dataSource.getConnection());

As you can see, the developer never gets a handle to the actual connection object and then tries to close the connection by passing dataSource.getConnection() as an argument to the closeObjects method.

The net effect is that the developer passes in a new connection into the closeObjects() method. The new connection is closed, leaving the original connection opened, thus a connection leak.

The corrected code follows: Continue reading Can you find the connection leak?

Comparing String objects with literals

This one’s pretty simple, but I find that it comes up in most code reviews that I perform. Developers commonly need to populate a String object, then check to see if the String contains a certain value;

String s;
s = someMethod();
if (s.equals("HelloWorld"))
    //Do something

Unfortunately, if someMethod() returns null for any reason, you end up getting a NullPointerException when you call s.equals() . Continue reading Comparing String objects with literals

Initialize Log4J in a web application with a ServletContextListener

While LogJj will self-initialize if it finds a file called or log4j.xml in the classpath, it will only read the file once at application startup.

I’ve often had the need to be able to change the logging level in a long-running application, such as a web application, so that I can switch logging to debug level as needed without requiring a restart.

Log4J provides configurator classes that will monitor a configuration file for changes and reload the configuration when the file changes. The implementation appears to spawn a background thread that sleeps for a specified interval, then wakes up and checks the configuration file for changes.

You can use this method by calling PropertyConfigurator.contigureAndWatch() or DOMConfigurator.configureAndWatch() methods. The challenge is that you should only call these methods once when your application starts up as each call to the above methods will result in a new thread to monitor the configuration file.

In many applications, it is a simple matter to call these methods only once. The question often comes up as to where to make the call to a ConfigureAndWatch method from within a web application. A collegue of mine once accidentally put this call in the main execution path of a high-traffic web application and brought the site down as the web application container couldn’t manage all the resulting threads.

I’ve seen several methods of ensuring that the ConfigureAndWatch method is only called once from within a web application, but I think the cleanest and simplest is to create a Context Listener to initialize Log4J.

The following example creates a ServletContextListener which will initialize Log4J when the application is loaded by the container, and will shut down logging for the application when it is unloaded. Continue reading Initialize Log4J in a web application with a ServletContextListener