ClassCastException/Receive Timed Out

[boxhead]

Hi All;

I realize that this question has been posted a thousand times. However, I have not been able to find an appropriate response to my problem. I am quite experienced with EJB's and Webapps. I feel I have done all that I can do to troubleshoot this one.

I have an EAR file with a web app and several ejbs. This EAR file runs fine on weblogic. Since I am a traditionalist, I disabled the UnifiedClassLoader with a jboss-app.xml file. When I worked with this problem on Saturday, my EAR was working in JBoss. But, when I started further dev tonight, a new problem occurred. The webapp is unable to communicate with the EJB's due to the infamous ClassCastException/Receive Timed Out problem. I have done the following, and I still am unable to solve the problem:

1. My jndi.properties is set correctly. I am able to gain an InitialContext to the server.
2. jboss.xml is setup correctly. the jndi-name element matches what the name I am trying to lookup from the webapp.
3. I cleared the /tmp directory out and made sure I have no offending jar files around that may contain stale classes. I also made sure my classpath was clear.

I spent several days now troubleshooting various problems with JBoss. It seems that my "standard" app is no longer standard because of all the little tweeks I have to put in just to get it running.

I am pretty stuck and frustrated on this one. Any suggestions would be appreciated.

Is there some debugging that I can enable to get further information on this problem? Does the ClassCastException indicate that JBoss is receiving a stale class? Or, could the ClassCast indicate something else?

[boxhead]

I did a bit a troubleshooting. Here's the stack trace:

javax.naming.CommunicationException: Failed to connect to server localhost:1099. Root exception is
java.lang.ClassCastException
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:199)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.boxhead.framework.ejb.EJBUtil.getEJB(EJBUtil.java:83)

I took a look at NamingContext.java:199 and found that the ClassCast is occurring while trying to do a cast to Naming. Naming appears to be a representation of a client side JNDI server. Therefore, it does not appear to be my code, but it appears to be something with the configuration of my server?

I am using a standard configuration. I made no modifications to any files in the standard jboss 3.2.3 implementation. I am passing the following properties to the server during startup:

jndi.provider.url=jnp://localhost:1099
jndi.initial.context.factory=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces

Suggestions would be appreciated ...

[boxhead]

Hi All;

I am really stuck on this problem and any help would be appreciated. I have been adding to the following thread, and if anyone has any input, please add to it. I am really stuck and frustrated. I believe this to be a problem within JBoss and not in my code.

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3832766#3832766

[boxhead]

I read somewhere in the forums that maybe I should not supply a hostname and factory while trying to get the initial context. I tried that, and that did not solve the problem. Hence, I did this:

props = new Properties();

// JBOSS DOES NOT LIKE THE FOLLOWING TWO LINES... GO FIGURE.
// props.put(Context.INITIAL_CONTEXT_FACTORY,providerFactory);
// props.put(Context.PROVIDER_URL, jndiProviderUrl);

if (user != null)
{
props.put(Context.SECURITY_PRINCIPAL, user);
}

if (password != null)
{
props.put(Context.SECURITY_CREDENTIALS, password);
}

propCache.put(key,props);
}

Context out=new InitialContext(props);

HELP!!!!!!!!!!!!!!!!

[starksm64]

The only way to get any further help is by posting a bug report to sourceforge with a testcase:
http://sourceforge.net/tracker/?group_id=22866&atid=376685