Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

How to lookup datasources with JNDI outside the J2EE container?

 
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, all.

I'm trying to connect to a datasource using the same JNDI lookup used in the J2EE container, but do the lookup OUTSIDE of the container.

Example:

public class BenJNDITest {
public static void main(String[] args)throws NamingException {

//Show classpath currently in use.
String classpath = System.getProperty("java.class.path");
System.out.println("Runtime classpath="+classpath);

java.util.Properties parms = new java.util.Properties();
parms.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
javax.naming.Context ctx = new javax.naming.InitialContext(parms);
javax.sql.DataSource ds =
(javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/mydb");
}
}
I suspect that there's a jar that needs to be added to the runtime classpath or perhaps a library that needs to be added to the build path in WSAD, coz the context lookup works ok when run under the app server. I just need it to run in the "straight" jvm.

The runtime classpath and error thrown is:

Runtime classpath=C:\Documents and Settings\bethridge\My Documents\IBM\wsappdev51\workspace\Ben1EARApplicationClient\appClientModule;C:\IMB\WSAD512\runtimes\base_v51\lib\j2ee.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\ivjejb35.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\servletevent.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\runtime.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\vaprt.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\ras.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\utils.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\rsaexternal.jar;C:\IMB\WSAD512\runtimes\base_v51\ lib\ecutils.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\ejbcontainer.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\ejbportable.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\wsexception.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\runtimefw.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\pmimpl.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\pm.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\appprofile.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\rsadaptercci.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\rsadapterspi.jar;C:\IMB\WSAD512\runtim es\base_v51\lib\ffdc.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\bootstrap.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\webcontainer.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\bsf.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\mofj2ee.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\processintf.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\commons-discovery.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\commons-logging-api.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\webservices.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\qname.jar;C:\ IMB\WSAD512\runtimes\base_v51\lib\wsdl4j.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\soap.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\soap-sec.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\ws-commons-logging.jar;C:\IMB\WSAD512\runtimes\base_v51\lib\querymd.jar

Exception in thread "main" javax.naming.ConfigurationException: The property com.ibm.ws.naming.wsn.factory.initial is not set. The most likely cause is that the jar which contains the file com/ibm/websphere/naming/jndiprovider.properties cannot be found by the class loader.
at com.ibm.websphere.naming.WsnInitialContextFactory.init_implClassCtor(WsnInitialContextFactory.java:192)
at com.ibm.websphere.naming.WsnInitialContextFactory.getInitialContext(WsnInitialContextFactory.java:110)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:256)
at javax.naming.InitialContext.init(InitialContext.java:232)
at javax.naming.InitialContext.<init>(InitialContext.java:208)
at benJNDITest.BenJNDITest.main(BenJNDITest.java:39)

I think that IBM is giving a good clue in the "most likely cause" phrase above, but I can't find the answer yet.

Is there a way to find out which jar that jndi.properties lives? and it is as simple as including that jar in the build path?

Fyi, this is WSAD 5.1.2, J2EE 1.3, and JDK 1.4.

Respectfully,
Ben
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have not found an answer yet, but I did find a handy "jar finder" plugin for WSAD, that some of you may also find useful.

It's at alphaworks here:

http://www.alphaworks.ibm.com/aw.nsf/reqs/jarclassfinder

It finds both class names and property file names embedded in jars, and you simply right-click on the entry in the find results to add the jar to your build path. Nice for quickly fixing those pesky NoClassDefFound exceptions.

Interestingly enough, the jar finder is not finding the jndiprovider.properties file anywhere in WSAD subdirs or WAS subdirs, so I'm going to check my entire c: drive now.

Ben
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Found the properties file. Was simply misusing the jar finder tool.

 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With the jar file containing the jndiprovider.properties added to the build path, I now get this error:

javax.naming.ConfigurationException: Name space accessor for the java: name space has not been set. Possible cause is that the user is specifying a java: URL name in a JNDI Context method call but is not running in a J2EE client or server environment.

Now THAT'S what I call a user-friendly error message
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fyi, I'm finding documentation at IBM that the namespace "java:" is accessible only by the J2EE application, implying that one cannot use it in a straight jvm.

http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rnam_dump_utility.html

Anyone think otherwise?

Ben
 
Ben Ethridge
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fyi, moving the class into an Application Client Project gets rid of the previous name space error, but generates another one, that I can't find discussion at IBM's website (or any other, for that matter). Here is the new error:

WSCL0100E: Exception received: java.lang.reflect.InvocationTargetException
Caused by: com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while the JNDI NamingManager was processing a javax.naming.Reference object. Root exception is java.lang.Exception: Failed security check. Client is not permitted to create connection factory FAB Datasource
at java.lang.Throwable.<init>(Throwable.java)...

As far as I know, I have all JAAS (and other) security turned off for my app server.

Ben
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keep reading in the InfoCenter. Do a search on "client-resource.xmi" This is something I cover in my book (Chapter 30) but the long and the short of it is you can't access a WAS 5.0 Datasource from an application client, period, end of story. You can (however) access a WAS 4.0 (backwards-compatibility) DataSource from an application client. If you use the Application Client Configuration tool to build the client-resource.xmi file you'll be able to make this work.

Kyle
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Kyle, but does this mean that if I have a DAO which is using Datasource connection then I can not call that DAO directly from my application client (because it is using Datasource) or I am missing something here??
 
We've gotta get close enough to that helmet to pull the choke on it's engine and flood his mind! Or, we could just read this tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
    Bookmark Topic Watch Topic
  • New Topic