Search WebSpherePower's 5,995 WebSphere, Java, and Eclipse article archive 
Home
EasyPrint
News details Click here for the RSS feed's XML code. This is not a browser URL.
Articles-only Click here for the RSS feed's XML code. This is not a browser URL.
Twitter Feed Click here for the Twitter feed.
JDBC DATASOURCE IN WEBSPHERE
Locate your JDBC DataSource in WebSphere Application Server using JNDI
By Jeff Chilton

"Success is simple. Do what's right, the right way, at the right time." -- Arnold H. Glasgow (American Psychologist)

When they start using the WebSphere Application Server, most developers who have worked in application server environments other than WebSphere usually struggle a bit when attempting to locate their JDBC DataSources. Although both the process and syntax are similar enough to appear quite familiar, they're just different enough to prevent success without a little minor tweaking from what works in other environments.

The Familiar Method
If you've done any work with JDBC DataSources in a Web application, you already understand the basic process: create an initial JNDI (Java Naming and Directory Interface) context, then use the context to perform a "lookup" to retrieve your DataSource. In Java code, this usually looks something like this (for simplicity's sake, the requisite try/catch block surrounding these statements has been removed):

InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/myDataSource");

While this looks great, and conforms to the established conventions used by most Web application servers, in a WebSphere Application Server this code will invariably result in the dreaded javax.naming.NameNotFoundException. To correctly locate your DataSource, you have two options, the first of which is a little simpler, but will result in some harmless messages cluttering up your server log file.

The WebSphere-specific Initial Context Factory
According to most IBM documentation and articles, the first thing you need to do when establishing an initial context is to set up the environment. The conventional code suggested for this operation looks something like this:

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.Websphere.naming.WsnInitialContextFactory");
InitialContext ctx = new InitialContext(env);

This works great, although I must admit, I'm not sure exactly what this buys you. I run a lot of open source code on WebSphere that was originally written for other environments; most such code does not contain this set-up process and it all seems to work fine as long as the DataSource name parameter is correct.


1  ·  2  ·  3  ·  Next »
Other articles you might like
Home > Java (6 articles)
   Use WebSphere to develop Java applications for Palm handhelds
   A simple introduction to J2EE
   Accessing remote AS/400 databases using JTOpen
Home > Database Integration (3 articles)
   Creating a MySQL data source using WebSphere Application Server
   Easily connecting to MySQL databases from WebSphere Studio
Get Weekly Email Updates
Subscribe to our regular weekly email newsletter. It's packed with tips, reviews, deep analysis, and the latest news.
 
Recent WebSpherePower Articles
A perfect 10: celebrating 10 years online
You can help bring security and safety back to White House email
Introducing the WebSpherePower RSS feeds
From New Jersey to Palm Bay, Florida
A WebSphere pot o' gold
How Elvis entered the building and CES went out the window
WebSphere Application Server 6: what's it all mean?
WebSpherePower News
All SaaS-Ed Up
WebSphere Application Server V7.0 Security Guide
PostgreSQL 8.4 Released, Now Easier to Use Than Ever
Sun's VirtualBox 3.0 exits betaland
Capitalware releases MQ Channel Monitor v1.0.0 for Free
OpsWise Software Announces Workload Automation Broker for Cloud Computing
O'Reilly Webcast: Cloud Computing: The Next Frontier for Open Source
>> Read all the news
More from the ZATZ journals
Computing Unplugged: Eight steps to successful and reliable home backups
David Gewirtz Online: CNN commentary and analysis
DominoPower: What to look for in a Domino-based document management solution
OutlookPower: Can Outlook run when it's not running (and other mysteries)?
-- Advertisement --

SECURE YOUR SITE WITH AN IRONCLAD SSL CERTIFICATE
An IronClad SSL Certificate helps you build an impenetrable fortress around your customer's credit card information. IronClad SSL Certificates are:

  • Fully validated
  • Up to 256-bit encryption
  • One, two, or three year validity (our Turbo SSL Certificates are valid up to 10 years)
  • 99% browser recognition
  • Stringent authentication
  • Around-the-clock customer support

Build trust. Protect your customers. Grow your online business.

Tap here now and be IronClad with SSL tonight.

ZATZ Home  ·  News  ·  Back Issues  ·  Credits/Trademarks ·  Link To Us
Copyright © 2009, ZATZ Publishing. All rights reserved worldwide.
Editor's Login