3 Replies Latest reply on Feb 14, 2002 8:18 AM by Paul Boddie

    JBoss 3 and Local Interfaces

    Brenton House Newbie

      Is it possible to access an EJB through local interfaces without having JBoss and the client (Tomcat or separate java app) integrated.

      I have created and deployed an EJB to JBoss with defined Remote and Local interfaces, however, I can only access the remote home via jndi lookup and not the local. My client app is a simple java class file that does a jndi lookup.

      I used JNDI Browser and the local shows up, but I get this error when I try to do a jndi lookup: javax.naming.NamingException: Could not dereference object

      I am running both on the same machine.

      Any help would be appreciated!!!

      thanks!

      brenton

        • 1. Re: JBoss 3 and Local Interfaces
          David Jencks Master

          ???

          local means "in the same vm" so if tomcat (or your client) and jboss are in different vms, you can't use local interfaces in tomcat (or your client). Was this your question?

          • 2. Re: JBoss 3 and Local Interfaces
            Brenton House Newbie

            ok.

            Is there some easy way (aside from waiting for a JBoss 3.0 / Tomcat Integration build) to run them in the same VM?

            And how would I run a client app ( simple java class ) in the same VM as JBoss.

            I would really like to test the local interfaces but am finding it difficult to find an environment to do this in!

            thanks!

            brenton

            • 3. Re: JBoss 3 and Local Interfaces
              Paul Boddie Newbie

              Yes, one of the problems with beans which must have local interfaces (CMP 2.0 entity beans, for example) is that it's hard to test them using a client! Still, what you can do is to provide remote interfaces for some of the beans and to invoke those from a client.

              Add "home" and "remote" elements to your deployment descriptor, provide remote home and bean interface definitions, and implement any new methods that are now necessary in your bean's implementation - you may need to be careful to avoid methods of the same name where only the return type is different, and I suppose that this is why people recommend a "session bean facade".

              So, you could implement a session bean which has remote interfaces and which relays calls to the local interfaces of your existing beans. That should also provide a way of testing them.