[jboss-dev] JBNAME-42: Was: Re: Howto debug jndi lookup issues?

Andrew Lee Rubinger andrew.rubinger at redhat.com
Mon Dec 7 15:57:56 EST 2009

I've always been frustrated by this too, and Brian's approach is pretty 

I've attached a patch to JBNAME-42 which will instead throw an Exception 

org.jnp.MissingObjectFactoryException: Could not obtain 
javax.naming.spi.ObjectFactory implementation referenced from JNDI at 
"missingObjectFactory"; perhaps missing from the ClassPath?: 

Here we override the SPI impl of:


..to catch the Reference returned and instead throw an Exception.  Brian 
notes by spec this is probably within reasonable:

http://java.sun.com/j2se/1.5/pdf/jndispi.pdf < Section 2.4

Anyone see reason why we cannot change this behavior?


On 12/07/2009 12:50 PM, Brian Stansberry wrote:
> Adding this to every test would be real ugly, but as a quick debug
> you can catch this and invoke Reference.getFactoryClassName(). It's the
> absence of that factory class that causes
> javax.naming.spi.NamingManager.getObjectInstance() to return the passed
> in Reference instance of creating the desired object.
> I opened a JIRA to have the JBoss NamingContext class detect this
> situation and add some useful debug output:
> https://jira.jboss.org/jira/browse/JBNAME-42
> On 12/07/2009 11:09 AM, Thomas Diesler wrote:
>> Still, is there a way to know what class is missing exactly?
>> On 12/07/2009 05:29 PM, Thomas Diesler wrote:
>>> Folks,
>>> java.lang.ClassCastException: javax.naming.Reference cannot be cast to
>>> org.jboss.test.osgi.jbosgi58.ejb.StatelessBean
>>>         at
>>> org.jboss.test.osgi.jbosgi58.OSGI58TestCase.testEJB(OSGI58TestCase.java:54)
>>> a JNDI client lookup may fail for various reasons . AFAIK, the above CCE
>>> happens because there is some calss missing on the client classpath.
>>> JNDI gives up internally and simply returns the reference.
>>> To solve the problem I could do
>>> <dependency>
>>> <groupId>org.jboss.jbossas</groupId>
>>> <artifactId>jboss-as-client</artifactId>
>>> <version>6.0.0.M1</version>
>>> <type>pom</type>
>>> </dependency>
>>> but this gives me an insanely big dependency tree
>>> (http://pastebin.com/m3776fc85). I'd much rather find out, what exactly
>>> is missing and use a client that contains just that.
>>> Is there a way to debug these kind of JNDI client issues?
>>> cheers
>>> -thomas

Andrew Lee Rubinger
Sr. Software Engineer
JBoss by Red Hat

More information about the jboss-development mailing list