Lookup
1 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Rohit_Vadera
Posted On:   Friday, August 8, 2003 05:02 AM

Can anyone please explain the diff between the two types of JNDI calls 1.One by setting the property 2.By calling staight away is first way is necessary if no then when it is necessary First Way System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); System.setProperty("java.naming.provider.url", "localhost:1099"); InitialContext jndiContext = new InitialContext(); out.println("Got context"); Object ref = jndiContext.lookup("interest/Interest"); out.println("Got reference"); InterestHome ho   More>>


Can anyone please explain the diff between the two types of JNDI calls



1.One by setting the property


2.By calling staight away



is first way is necessary if no then when it is necessary



First Way


System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");


System.setProperty("java.naming.provider.url", "localhost:1099");
InitialContext jndiContext = new InitialContext(); out.println("Got context");


Object ref = jndiContext.lookup("interest/Interest"); out.println("Got reference");


InterestHome home = (InterestHome) PortableRemoteObject.narrow (ref, InterestHome.class);



Second Way by staright away calling


InitialContext jndiContext = new InitialContext();

out.println("Got context");


Object ref = jndiContext.lookup("interest/Interest");

out.println("Got reference");


InterestHome home = (InterestHome) PortableRemoteObject.narrow (ref, InterestHome.class);



Hope you understood wat i mean


Thanx for the explanation i will get


Rohit

   <<Less

Re: Lookup

Posted By:   Christopher_Koenigsberg  
Posted On:   Friday, August 8, 2003 07:17 AM

Here's what I found. Actually there is a third way you didn't mention, which is the most useful in some circumstances...


I have a web app that gets deployed sometimes on different brands of servlet containers and/or full J2EE app servers. It needs to do a JNDI lookup and find a JMS queue on a single brand (JBoss) of remote app server, no matter where it is deployed.



If you put the settings into the jndi.properties (e.g. the naming factory, naming provider url, plus one more, I forget) and use the default zero-arg constructor ("new InitialContext()") then you are "at the mercy" of the particular container engine, for what it adds to those configuration settings. It can prepend its own URL's, classes, locations etc. to the values you have given in jndi.properties. It is trying to be helpful I guess, and use its own libraries from its own shared jar files, etc.



I found that Tomcat and Weblogic were both doing some of this, each prepending something to a different property, neither of which we wanted. We had the JBoss jar files in our War file and we only wanted to use them, to directly contact the remote JBoss server's JNDI for out initial context, not interacting with the local JNDI on whatever server we were deployed on, so we would not have to mess with that local server's configuration.



So we got around this, by changing our code to explicitly call the "InitialContext(env)", where "env" is a HashTable of the properties and values we want (I directly cut and pasted from sample code which is all over the place, in jndi how-to documentation).

This way it seems that the container doesn't mess around, doesn't prepend anything to what we have given. So we give the names of the JBoss jar files, the JBoss "jnp" protocol and the JBoss server hostname, etc. and it works, regardless of whether it is deployed on a Tomcat, or Weblogic, or Websphere, server.



But if you are not in our unusual (?) situation you may want to have the local container help you, by using the default zero-arg InitialContext() constructor, and letting the container prepending its own provider, naming factory etc., so you may want to set the system properties in your jndi.properties and let it prepend to them.

About | Sitemap | Contact