14 Replies Latest reply: Sep 22, 2012 1:13 PM by rakesh c RSS

    ClassCastException after JNDI lookup

    tperrigo Newbie

      I've got a very simple stateless session bean:

      @Stateless
      @Remote(ProcessAdminRemote.class)
      public class ProcessAdminEJB implements ProcessAdmin {
      ...
      }
      


      ...with the following business and Remote interfaces (no local interface):
      public interface ProcessAdmin {
      ...
      }
      
      public interface ProcessAdminRemote extends ProcessAdmin {
      }
      
      


      Everything seems to deploy just fine, but when I try to do the following JNDI lookup, I get a ClassCastException:

      InitialContext ctx = new InitialContext();
      final String jndiName = "ProcessAdminEJB/remote";
      Object o = ctx.lookup(jndiName);
      if ( o == null ) {
       System.err.println("unable to find " + jndiName);
      } else {
       System.out.println("retrieved instance of "+o.getClass().getName());
      }
      // the following line causes the ClassCastException...
      ProcessAdmin ejb = (ProcessAdmin)o;
      


      When I print out the name of the instance returned by the JNDI lookup, I find that it is an instance of javax.naming.Reference.

      I really have no idea what I'm doing wrong...I've found a couple example EJB3 stateless session beans, and they are pretty much exactly the same as my setup. I'm using JBossAS 5.0.0.CR2. This is driving me nuts...any help would be extremely appreciated!

      Thanks in advance,
      Tim



        • 1. Re: ClassCastException after JNDI lookup
          Arthur D'Alessandro Newbie

          Try, the ProcessAdminRemote is the remote interface your defining within your ejb

          
          ProcessAdminRemote ejb = (ProcessAdminRemote)o;
          


          • 2. Re: ClassCastException after JNDI lookup
            tperrigo Newbie

            Thanks for the speedy reply...I have tried casting to the Remote Interface (rather than the business interface), but I get the same ClassCastException; I just re-ran to confirm. The object returned is an instance of javax.naming.Reference, and any attempt to cast to the business or Remote interface results in a ClassCastException.

            Thanks,
            Tim

            • 3. Re: ClassCastException after JNDI lookup
              Arthur D'Alessandro Newbie

              Just some things;

              Your EJB implements the ProcessAdmin vs the ProcessAdminRemote interface, all my EJB's implement the local and remote interfaces.

              I also define the JNDI binding; although this is all from JBOSS 4.2.2, and not sure specifically about JBOSS 5.

              • 4. Re: ClassCastException after JNDI lookup
                tperrigo Newbie

                I've also tried having the ProcessAdminEJB implement the Remote Interface, rather than the business interface, with the same results. I don't know if this will be of any help, but here is the console output from the server when I deploy the jar file containing the EJB:

                10:45:58,444 INFO [EJBContainer] STARTED EJB: werner.opt.process.admin.ejb.ProcessAdminEJB ejbName: ProcessAdminEJB
                10:45:58,448 WARN [SessionSpecContainer] Populating JBoss-specific annotation metadata manually until done by deployers: jboss.j2ee:ear=opt_process_admin.jar,jar=opt_process_admin.jar,name=ProcessAdminEJB,service=EJB3
                10:50:04,217 INFO [SessionSpecContainer] Stopping jboss.j2ee:ear=opt_process_admin.jar,jar=opt_process_admin.jar,name=ProcessAdminEJB,service=EJB3
                10:50:04,218 INFO [EJBContainer] STOPPED EJB: werner.opt.process.admin.ejb.ProcessAdminEJB ejbName: ProcessAdminEJB
                10:50:04,395 WARN [EjbMetadataJndiPolicyDecoratorDeployer] Defaulting to DefaultJndiBindingPolicy of "org.jboss.metadata.ejb.jboss.jndipolicy.plugins.BasicJndiBindingPolicy" for Session Bean ProcessAdminEJB
                10:50:04,435 INFO [JBossASKernel] Created KernelDeployment for: opt_process_admin.jar
                10:50:04,435 INFO [JBossASKernel] installing bean: jboss.j2ee:ear=opt_process_admin.jar,jar=opt_process_admin.jar,name=ProcessAdminEJB,service=EJB3
                10:50:04,435 INFO [JBossASKernel] with dependencies:
                10:50:04,435 INFO [JBossASKernel] and demands:
                10:50:04,435 INFO [JBossASKernel] jboss.ejb:service=EJBTimerService
                10:50:04,435 INFO [JBossASKernel] and supplies:
                10:50:04,435 INFO [JBossASKernel] Class:werner.opt.process.admin.ejb.ProcessAdminRemote
                10:50:04,435 INFO [JBossASKernel] jndi:ProcessAdminEJB/remote
                10:50:04,435 INFO [JBossASKernel] jndi:ProcessAdminEJB/remote-werner.opt.process.admin.ejb.ProcessAdminRemote
                10:50:04,435 INFO [JBossASKernel] Added bean(jboss.j2ee:ear=opt_process_admin.jar,jar=opt_process_admin.jar,name=ProcessAdminEJB,service=EJB3) to KernelDeployment of: opt_process_admin.jar
                
                


                Thanks again for the quick response...please let me know if you think of anything else I could try!

                Tim

                • 5. Re: ClassCastException after JNDI lookup
                  Peter Johnson Master

                  Try switching around the annotations like this:

                  @Remote
                  public interface ProcessAdminRemote extends ProcessAdmin {...}
                  
                  @Stateless
                  public class ProcessAdminEJB implements ProcessAdminRemote {...}



                  • 6. Re: ClassCastException after JNDI lookup
                    tperrigo Newbie

                    Same behavior...the JNDI lookup returns a javax.naming.Reference; the attempt to cast to the Remote Interface causes a ClassCastException.

                    • 7. Re: ClassCastException after JNDI lookup
                      jaikiran pai Master

                      Where is the lookup happening from? Is it a standalone Java program? If yes, are you including the jbossall-client.jar and the jar files referenced in its MANIFEST.MF, in your client classpath? Ensure that these jar files are the same as that on the server.

                      If you are doing the lookup within the container (like from servlet or jsp), make sure that you are not packaging any jboss related jar files (like jbossall-client.jar) inside your application.

                      Finally, if none of this helps you fix the issue, please post the output of the JNDI tree which you can view by following the steps mentioned here http://www.jboss.org/community/docs/DOC-9583

                      • 8. Re: ClassCastException after JNDI lookup
                        Andrew Rubinger Master

                        A CCE from javax.naming.Reference is usually a sign that the requisite ObjectFactory is not on your client classpath.

                        Check that you've got jbossall-client.jar on there.

                        S,
                        ALR

                        • 9. Re: ClassCastException after JNDI lookup - SOLVED
                          tperrigo Newbie

                          Ok, I followed the advice from the last couple of posters, and adding ALL of the jars from the jbossall-client.jar's Manifest to my classpath FINALLY made my test work! I had jbossall-client.jar in my classpath originally, along with (what I had thought) were all the jars I would need (basically, the equivalent versions of jars from earlier JBoss versions), leaving out jars like the IIOP jar, etc, that I thought I didn't neeed. Turns out I was wrong...I couldn't get my test to work until I added _every_ jar from the Manifest to my classpath. Once I did that, my test worked!

                          Thanks to everyone for your help with this (very frustrating) problem. I sincerely appreciate everyone's assistance.

                          Tim

                          • 10. Re: ClassCastException after JNDI lookup
                            Ralf Heydenreich Newbie

                            Hi,
                            can you please post the list of jars you've added? I've looked into the MANIFEST of jbossall-cient.jar, but there's no CLASSPATH at all (only some vendor specific information). And I think that I've the same problem. I'm using JBoss 4.2.3 GA.

                            Here's my console output:

                            Exception in thread "main" java.lang.ClassCastException: $Proxy1
                             at org.jboss.naming.client.java.javaURLContextFactory$EncContextProxy.invoke(javaURLContextFactory.java:129)
                             at $Proxy0.lookup(Unknown Source)
                             at javax.naming.InitialContext.lookup(Unknown Source)
                             at de.my.class.MyFailingClass.main(MyFailingClass.java:22)
                            


                            TIA,
                            Ralf

                            • 11. Re: ClassCastException after JNDI lookup
                              Andrew Rubinger Master

                              jbossall-client.jar did not become a MANIFEST-only classpath structure until AS 5.0.0.CR2.

                              S,
                              ALR

                              • 12. Re: ClassCastException after JNDI lookup
                                jaikiran pai Master

                                As Andrew mentioned, its only starting JBoss-5 CR2 the jbossall-client.jar is a manifest only jar. So for JBoss-4.2.3 GA, all you have to do is place the %JBOSS_HOME%/client/jbossall-client.jar in the client (de.my.class.MyFailingClass) classpath. Have you done that?

                                • 13. Re: ClassCastException after JNDI lookup
                                  Ralf Heydenreich Newbie

                                  Ah, thanks, this helped. I forgot to do this in the Eclipse project settings.

                                  Greetings,
                                  Ralf.

                                  • 14. Re: ClassCastException after JNDI lookup
                                    rakesh c Newbie

                                    thanks Pai, worth info on the problem.