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