2 Replies Latest reply on Nov 29, 2011 5:28 AM by Prasad Deshpande

    Difference among JNDI names

    jaabax Newbie

      hi

      I've deployed a HelloWorld application composed of an EAR with a WAR and an EJB package with just one @Stateless and @Local EJB

      the provided JNDI names on the JBoss console for my EJB (HelloWorldEJB) was:

       

      {code}java:global/helloworld/helloworld.jar/HelloWorldEJB!org.test.HelloWorldEJB

      java:app/helloworld.jar/HelloWorldEJB!org.test.HelloWorldEJB

      java:module/HelloWorldEJB!org.test.HelloWorldEJB

      java:global/helloworld/helloworld.jar/HelloWorldEJB

      java:app/helloworld.jar/HelloWorldEJB

      java:module/HelloWorldEJB{code}

       

      what's the difference of the 6 provided JNDI names?

      when should I use each of them?

      is there a place on the docs that explains the difference of the 6 provided JNDI names?

      thanks in advance!

        • 1. Re: Difference among JNDI names
          Stephen Coy Master

          A large part of this is documented in the EJB 3.1 spec "JSR 318: Enterprise JavaBeans,Version 3.1", section 4.4

          • 2. Re: Difference among JNDI names
            Prasad Deshpande Expert

            jaabax wrote:

            java:global/helloworld/helloworld.jar/HelloWorldEJB!org.test.HelloWorldEJB
            java:app/helloworld.jar/HelloWorldEJB!org.test.HelloWorldEJB
            java:module/HelloWorldEJB!org.test.HelloWorldEJB
            java:global/helloworld/helloworld.jar/HelloWorldEJB
            java:app/helloworld.jar/HelloWorldEJB
            java:module/HelloWorldEJB

             

             

            what's the difference of the 6 provided JNDI names?

            when should I use each of them?

            Generally, JNDI names which has fully qualified class with it, like e.g. "!org.test.HellowWorldEJB" are more useful when your bean has more than one interface (Local & Remote) implemented that's when it's used to distinguish what you want to lookup for.. e.g.

             

            if an EJB say org.test.HellowWorldEJB has Remote (org.test.HellowWorldRemote) & Local (org.test.HellowWorldLocal) implemented, then lookup like ctx.lookup("java:global/helloworld/helloworld.jar/HelloWorldEJB") becomes ambiguous to case to, in that case you use ctx.lookup("java:global/helloworld/helloworld.jar/HelloWorldEJB!org.test.HellowWorldRemote") to get exactly the interface implementation..

             

            That leaves 3 names java:global, java:app, java:module

             

            Let's say you have an ear helloworld.ear (application) with EJB's packaged in helloworld.jar (a module) alongwith few other war files (each war is a separate module) and another EJB jar say "byeworld.jar" (another module), then,

             

            Each module defines it's own namespace (called java:module), a lookup to java:module by a component will list only other components from the same module.

             

            Similarly, each application (say EAR file in this case or a WAR file which is deployed on it's own without being packaged in EAR) define it's own namespace (java:app). A component in an application can access anything listed in java:app namespace. So, if you want a component from one module to be accessible from another, bind it in java:app namespace.

             

            Now, If you want anything to be accessible outside application, but in the same JVM, bind it to java:global namespace. e.g. if you want HelloWorldEJB to be accessible in another application (say test.ear) deployed in the same application server, bind it to java:global namespace.

             

            so In short, all these 3 namespaces (java:global, java:app, java:module) define the scope of availability of component.