Discussions

EJB programming & troubleshooting: ejb-ref tag

  1. ejb-ref tag (5 messages)

    Can somebody verify my understanding.

    What is the use of ejb-ref?

    ejb-ref is used to tell the deployer that this bean will be referring to other bean with this name.

    Is there any other use.

    Threaded Messages (5)

  2. ejb-ref tag[ Go to top ]

    When you deploy an EJB to a server, you can assign its home interface any JNDI you like. This is a potential problem, because the JNDI name in production may be different from the one used in development.

    <ejb-ref> allows you to define an "reference" JNDI name that is fixed. This "reference" JNDI name is mapped to the "real" JNDI name when you deploy it to production. This means you can safely use the "reference" JNDI in your code. That is the theory, anyway.

    Personally, I just come up with a decent naming scheme for the "real" JNDI names and use those for both development and production.
  3. ejb-ref tag[ Go to top ]

    Does declaring ejb-ref tag itself means that bean is attched to that ref-name
    or we need to do anything else when deploying the bean that is referred.
  4. ejb-ref tag[ Go to top ]

    When you deploy the EJB, the ejb-ref name does need to be mapped to the "real" JNDI name. This has to be done in a server-specific way. This complicates deployment, and is the main reason I don't like or use this feature of EJBs.
  5. What is the advantage of using java:comp/env/ejb/jndiname when we are calling one ejb from another ejb in the same container.

    For using java:comp/env/ejb/name is it compuslory that both the beans have to be in the same jar file.
  6. This is not correct. The "java:comp/env/..." prefix can be translated to the real JNDI name of an EJB anywhere else (another JAR or another EAR). You are not tied to the same JAR.

    The "java:comp/env/..." has the following benefits:

    1. The dependency of an external EJB isn't hidden inside an application - you are forced to declare an ejb-ref of ejb-local-ref in web.xml, and you are forced to bind this reference to a real JNDI name in a complementary descriptor (like jboss-web.xml in JBoss or weblogic.xml in WebLogic). Not hidden dependencies eases administration, or so I believe;

    2. The hard-coded "java:comp/env/..." (and its ejb-ref in web.xml) is ALWAYS portable. A hard-coded real JNDI name may not be portable;

    3. If the EJB has both local and remote interfaces, the ejb-local-ref is the only way your application can access its local interfaces in WebSphere (the real JNDI name always returns the remote home stub);

    Have in mind that any ejb-ref or ejb-local-ref must be translated to real JNDI names by server-specific descriptors. If that bothers you, so use the real JNDI name - it works ok except in some cases on WebSphere.