InitialContext.lookup() returns null

John Wrynn

unread,

Jul 23, 2001, 12:29:02 PM7/23/01

to

Hi,

I am running WAS 3.5.3 on Windows 2000. This problems also happens on NT
4.0.

We have been using something similar to the below snippet to get references
to EJBs via JNDI:

[ ... ]
// We actually get these strings from parameter files - they are coming
in OK, not null
String url = "iiop://john_nt:900";
String spi = "com.ibm.ejs.ns.jndi.CNInitialContextFactory";
String dsm_factory =
"java:comp/env/com/entigo/beans/dsm/DistributedSessionManagerHome";

Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, spi );
props.put(Context.PROVIDER_URL, url );

InitialContext cntx = new InitialContext(props);
Object result = cntx.lookup(dsm_factory);
[ ... ]
We are bombing on the last line here, where we are doing the lookup - it's
returning nulls.

Some observations:
a) For the url, we have tried short host name, FQ host name, and IP number -
none work.
b) I verified that the JNDI home name for dsm_factory matches what was
spec'd in VisualAge AND in WebSphere.
c) I thought that I might have stale JNDI home names left over from previous
software versions. I wiped out all my old app servers, containers, and
servlet engines and created new ones - still getting the nulls.
d) this used to work - it started dying when we tried to load a new version
of our EJBs.

I see they talk about Context.lookup() not working on the InfoCenter (see
sec 8.7 Using Application Level Facilities). None of the tricks listed
under the section "A summary of EJB failures" works.

Any ideas how to get around this one?

--John Wrynn
jwr...@entigo.com

Randy Schnier

unread,

Jul 23, 2001, 9:57:30 PM7/23/01

to

The use of java:comp/env local namespaces is not supported until WAS 4.0.
However, you can easily work around this by doing a direct JNDI lookup using
whatever name you have defined in the EJB's deployment descriptor. That is, if
you defined "com/entigo/beans/dsn/DistributedSessionManagerHome" as the name for
your EJBHome in VAJ, that's the same string you would look it up with (without
the java:comp/env at the beginning).

Randy Schnier

John Wrynn wrote:

--
Randy Schnier

John Wrynn

unread,

Jul 24, 2001, 10:56:25 AM7/24/01

to

Randy,

We have been successfully using java:comp/env for the past 4 months. How
come it quit working all of a sudden?

I actually got the idea for using this style of JNDI names from IBM - see
Redbook SG24-5956-00, Chapter 7.

--John Wrynn
jwr...@entigo.com

"Randy Schnier" <rsch...@chartermi.net> wrote in message
news:3B5CD60A...@chartermi.net...

Randy Schnier

unread,

Jul 24, 2001, 11:50:05 AM7/24/01

to

John,
I looked at the redbook you mentioned (section 7.4.2.3). It's a workaround for
the lack of java:comp/env support prior to 4.0, basically you bind your EJBHome
into the JNDI namespace with "java:comp/env/" actually defined as the beginning
of the global JNDI name. This should work, so the most likely thing to double
check is that the home name in the deployment descriptor of your new version of
the EJB does in fact also have "java:comp/env/" at the beginning. Another
possibility, though less likely, is that another EJB you're loading into
WebSphere has a conflicting home name.

Randy

John Wrynn

unread,

Jul 25, 2001, 8:03:45 AM7/25/01

to

Randy,

Comments in line:

"Randy Schnier" <rsch...@us.ibm.com> wrote in message
news:3B5D992D...@us.ibm.com...

> John,
> I looked at the redbook you mentioned (section 7.4.2.3). It's a
workaround for
> the lack of java:comp/env support prior to 4.0, basically you bind your
EJBHome
> into the JNDI namespace with "java:comp/env/" actually defined as the
beginning
> of the global JNDI name.

Yep! That's the section of the redbook.

> This should work, so the most likely thing to double
> check is that the home name in the deployment descriptor of your new
version of
> the EJB does in fact also have "java:comp/env/" at the beginning.

We have rebuilt our EJBs several times, using VisualAge. Yesterday, I
started from scratch and built the EJBs using jetace - same
NullPointerException when we go to do a lookup.

Every time we built the EJBs, we checked the JNDI home names - they always
started w/ "java:comp/env/"

>Another
> possibility, though less likely, is that another EJB you're loading into
> WebSphere has a conflicting home name.
>

This is what I'm thinking now - it has me worried, because I removed the old
EJBs before attempting to load the new ones. Do we have a stale reference
hanging around in our JNDI namespace???

Just wondering if anyone from IBM is following this thread?

Randy Schnier

unread,

Jul 26, 2001, 12:03:05 AM7/26/01

to

John,
I am from IBM, and a member of the team that develops WebSphere. A number of us
monitor this newsgroup (often outside of our "normal" jobs) because it helps us
keep in touch with the issues (good and bad) that customers are experiencing
with the product. Due to the volume of traffic however, we can't guarantee
responses or direct solutions to all problems reported here; it's informal
"peer-to-peer" support. For those issues where you have an urgent or critical
need for assistance, your best avenue is to contact IBM product support.

I am a little unclear on one aspect of the problem you are seeing: are you
getting a null back from the lookup, or having a NullPointerException thrown by
the JNDI InitialContext object when you do the lookup?

One other area of interest is: What else has changed since this last worked.
For example, any WebSphere PTFs or e-fixes applied? How about to VAJava? It
is possible that the JNDI code is getting confused by the "java:comp" part of
the binding name, or perhaps some other part of the name, but in order for it to
start behaving this way it seems like some part of the environment would have
had to change.

It is possible that there is a reference hanging around in the namespace, but
the server re-binds all the home names into the namespace each time it starts
up, so as long as the JNDI name in your bean's deployment descriptor is valid
and unique, there should be something in the namespace with that name.

Randy

John Wrynn wrote:

> Just wondering if anyone from IBM is following this thread?

--
Randy Schnier

John Wrynn

unread,

Jul 26, 2001, 12:16:18 PM7/26/01

to

"Randy Schnier" <rsch...@chartermi.net> wrote in message

news:3B5F9679...@chartermi.net...

> John,
> I am from IBM, and a member of the team that develops WebSphere. A number
of us
> monitor this newsgroup (often outside of our "normal" jobs) because it
helps us
> keep in touch with the issues (good and bad) that customers are
experiencing
> with the product. Due to the volume of traffic however, we can't
guarantee
> responses or direct solutions to all problems reported here; it's informal
> "peer-to-peer" support. For those issues where you have an urgent or
critical
> need for assistance, your best avenue is to contact IBM product support.
>

I really appreciate your assistance with this problem Randy!

> I am a little unclear on one aspect of the problem you are seeing: are you
> getting a null back from the lookup, or having a NullPointerException
thrown by
> the JNDI InitialContext object when you do the lookup?
>

We are actually getting a NullPointerException thrown by the context when we
attempt to do the lookup. Here's a fragment of the stack trace:

[01.07.25 17:01:32:326 EDT] 5eae4a0f WebGroup A SRVE0092I: [Servlet
LOG]: "auth: User Session[]-Caught exception initializing AuthServlet: ":
javax.naming.NamingException: Error during resolve. Root exception is
java.lang.NullPointerException

at com.ibm.ejs.ns.jndi.CNContextImpl.doLookup(CNContextImpl.java:744)

at com.ibm.ejs.ns.jndi.CNContextImpl.lookup(CNContextImpl.java:590)

at javax.naming.InitialContext.lookup(InitialContext.java:349)

at
com.entigo.beans.dsm.DistributedSessionManagerHelper.<init>(DistributedSessi
onManagerHelper.java:112)

at com.entigo.servlets.AuthServlet.init(AuthServlet.java:269)

at
com.ibm.servlet.engine.webapp.StrictServletInstance.doInit(ServletManager.ja
va:604)

at
com.ibm.servlet.engine.webapp.StrictLifecycleServlet._init(StrictLifecycleSe
rvlet.java:136)

at
com.ibm.servlet.engine.webapp.PreInitializedServletState.init(StrictLifecycl
eServlet.java:244)

at
com.ibm.servlet.engine.webapp.StrictLifecycleServlet.init(StrictLifecycleSer
vlet.java:102)

at
com.ibm.servlet.engine.webapp.ServletInstance.init(ServletManager.java:284)

at javax.servlet.GenericServlet.init(GenericServlet.java:258)

at
com.ibm.servlet.engine.webapp.ServletManager.addServlet(ServletManager.java:
76)

at
com.ibm.servlet.engine.webapp.WebAppServletManager.loadServlet(WebAppServlet
Manager.java:91)

at
com.ibm.servlet.engine.webapp.WebAppServletManager.getServletReference(WebAp
pServletManager.java:135)

at
com.ibm.servlet.engine.webapp.WebApp.getServletReference(WebApp.java:293)

at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcherInfo.calculateInfo(WebA
ppRequestDispatcherInfo.java:151)

at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcherInfo.<init>(WebAppReque
stDispatcherInfo.java:50)

at
com.ibm.servlet.engine.webapp.WebApp.getRequestDispatcher(WebApp.java:962)

at
com.ibm.servlet.engine.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.
java:73)

at
com.ibm.servlet.engine.invocation.CachedInvocation.handleInvocation(CachedIn
vocation.java:67)

at
com.ibm.servlet.engine.srp.ServletRequestProcessor.dispatchByURI(ServletRequ
estProcessor.java:155)

at
com.ibm.servlet.engine.oselistener.OSEListenerDispatcher.service(OSEListener
.java:300)

at
com.ibm.servlet.engine.oselistener.SQEventListenerImp$ServiceRunnable.run(SQ
EventListenerImp.java:230)

at
com.ibm.servlet.engine.oselistener.SQEventListenerImp.notifySQEvent(SQEventL
istenerImp.java:104)

at
com.ibm.servlet.engine.oselistener.serverqueue.SQEventSource.notifyEvent(SQE
ventSource.java:212)

at
com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRu
nnable.notifyService(SQWrapperEventSource.java:353)

at
com.ibm.servlet.engine.oselistener.serverqueue.SQWrapperEventSource$SelectRu
nnable.run(SQWrapperEventSource.java:220)

at
com.ibm.servlet.engine.oselistener.outofproc.OutOfProcThread$CtlRunnable.run
(OutOfProcThread.java:248)

at java.lang.Thread.run(Thread.java:481)

----- Begin backtrace for rootCause

java.lang.NullPointerException