ClassCastException when using jndi lookup in simple project

[bjohnsonjr]

Using version 5.0.0 CR1 a simple project was setup including an EJB3 bean project, and a web project within an ear.

The bean project contained 1 local stateless bean.

The web project contained a servlet which attempted to lookup the bean using the standard jndi lookup.

When calling the lookup, the object is properly returned, but the interface is not set on the proxy and a ClassCastException is thrown. Debugging the proxy shows an inner object of the proxy has the proper interface, but is not exposed.

The JNDI TreeView shows the proxy and the interface.

This was working fine in 5.0.0 beta4.

Is there a configuration change needed with the CR1 release?

public interface Foo {

 String doFoo();
}

@Stateless
@Local(Foo.class)
public class Bar implements Foo {
 @Override
 public String doFoo() {
 return "Hello";
 }

}

public class Lookup extends HttpServlet {

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException,
 IOException {

 try {
 Object obj = new InitialContext().lookup("jbosstest-ear/" + Bar.class.getSimpleName() + "/local");
 Foo foo = (Foo) obj;
 System.out.println(foo.doFoo());
 }
 catch (NamingException e) {
 e.printStackTrace();
 }
 }
}

java.lang.ClassCastException: $Proxy128 cannot be cast to Foo
 at Lookup.doGet(Lookup.java:26)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:183)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:189)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:90)
 at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:96)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:619)

+- jbosstest-ear (class: org.jnp.interfaces.NamingContext)
 | +- Bar (class: org.jnp.interfaces.NamingContext)
 | | +- local (proxy: $Proxy206 implements interface org.jboss.ejb3.proxy.JBossProxy,interface Foo)

[jaikiran]

Are you sure, this is not a classloading issue? Are you packaging the bean interface(s) in more than one place (probably the jar and the war)? See this http://wiki.jboss.org/wiki/ClassCastExceptions for more details.

[bjohnsonjr]

Thank you for the reply, I had read the link you provided and checked that there is only one copy of the class file in the jar and not in the war project.

I had noticed forums regarding the new classloading in JBoss 5, but none made it clear how to setup it up or when it is needed. So it may be possible this is a classloading issue and I would need assistance setting up the configuration files.

[jaikiran]

Are you packaging your application as a EAR (containing the jar and the war)? Or are you deploying the jar and the war separately? Post the output of the following commands (depending on how you package the application):

If deployed as a EAR:

jar -tf myapp.ear

If jar and war are deployed separately:

jar -tf myapp.jar
jar -tf myapp.war

[bjohnsonjr]

Here is the content of my ear project:

jbosstest-web.war/
jbosstest-web.war/META-INF/
jbosstest-web.war/META-INF/MANIFEST.MF
jbosstest-web.war/WEB-INF/
jbosstest-web.war/WEB-INF/classes/
jbosstest-web.war/WEB-INF/classes/foo/
jbosstest-web.war/WEB-INF/classes/foo/Lookup.class
jbosstest-web.war/WEB-INF/web.xml
META-INF/
testJbossCR1-beans.jar/
testJbossCR1-beans.jar/foo/
testJbossCR1-beans.jar/foo/Bar.class
testJbossCR1-beans.jar/foo/Foo.class
testJbossCR1-beans.jar/META-INF/
testJbossCR1-beans.jar/META-INF/MANIFEST.MF

[jaikiran]

testJbossCR1-beans.jar/foo/Foo.class

local (proxy: $Proxy206 implements interface org.jboss.ejb3.proxy.JBossProxy,interface Foo)

Are you sure you posted the correct logs and JNDI output? You seem to have a interface named Foo under the package foo (based on your packaging). However, the exception stacktrace and the jndi tree show that the interface Foo is present in the default package.

[bjohnsonjr]

Sorry for the confusion. During the original post, I had all classes in the default package.
While attempting trial and error, I decided to try putting them in actual packages to make sure this was not a cause of the classes not being found.

Therefore, when I ran the command to show the contents, the packages had changed. In the current state it showed in the JNDITree with the
interface foo.Foo as expected.