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

[Andrew Lee Rubinger]

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

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

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

Here we override the SPI impl of:

http://java.sun.com/javase/6/docs/api/javax/naming/spi/NamingManager.html#getObjectInstance(java.lang.Object,%20javax.naming.Name,%20javax.naming.Context,%20java.util.Hashtable)

..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?

S,
ALR

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
http://exitcondition.alrubinger.com
http://twitter.com/ALRubinger