14 Replies Latest reply: Feb 4, 2006 4:18 PM by Ralf Quebbemann RSS


Dornus Novice

Which way should we call InitalContext now?

According to this file
http://docs.jboss.org/ejb3/embedded/embedded-tutorial/embedded-war/src/EmbeddedEJB3.jsp it looks like it can be called both ways.

Way #1:

InitialContext ctx = getInitialContext();
 CustomerDAOLocal local = (CustomerDAOLocal) ctx.lookup(CustomerDAOLocal.class.getName());

Queue queue = (Queue) getInitialContext().lookup("queue/mdbtest");

public static InitialContext getInitialContext() throws Exception
 Hashtable props = getInitialContextProperties();
 return new InitialContext(props);

 private static Hashtable getInitialContextProperties()
 Hashtable props = new Hashtable();
 props.put("java.naming.factory.initial", "org.jnp.interfaces.LocalOnlyContextFactory");
 props.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
 return props;

  • 1. Re: InitialContext()
    Bill Burke Master

    Yikes, I think I forgot to test the embedded war example!

    it should be:

     CustomerDAOLocal local = (CustomerDAOLocal) ctx.lookup("CustomerDAOBean/local");

  • 2. Re: InitialContext()
    Dornus Novice

    So then it was choice 3? :)

    so when do we use way #2? Where we have to define our own static hashtable. Or is that just for a specific case that most people won't use?

    Also, what do we do with way#3 when it's not specifically set to remote or local? My beans currently don't have a local or remote tag...just public interface MyClassName

  • 3. Re: InitialContext()
    Bill Burke Master

    There two different concepts here:

    #1 Getting a javax.naming.InitialContext. When using E-EJB3 within a WAR (in Tomcat for example), you must set the InitialContext properties as shown as JBoss uses its own JNDI implementation within E-EJB3 even within Tomcat. We may fix this in the future.

    #2 The lookup of the EJB which, by default uses the form:

    "EJB-NAME/local" or "EJB-NAME/remote". See the docs, WIKI, and release notes for more detail.

  • 4. Re: InitialContext()
    Dornus Novice

    So if my Stateless bean does not have a local/remote, I cannot call it using InitialContext???

    I'm assuming this is what's leading to my

    javax.naming.NameNotFoundException: myPath.myClass not bound


    Do I have to make an empty @Local bean which extends my interface class?

  • 5. Re: InitialContext()
    Bill Burke Master

    Your bean class must implementat at least one interface. If these interfaces are nto annotated with @Remote or @Local, the EJB container assumes they are local interfaces. To look up a local interface do:


    where EJB-NAME is the unqualified bean class name

  • 6. Re: InitialContext()
    Dornus Novice

    ok, I already have it set up like that, so all my beans have a local interface. Now that I changed the InitialContext.lookup to "BeanName/local") I am getting another error as a result

    Caused by: java.lang.RuntimeException: For EJB MyCustomBean could not find jndi binding based on interface only for @EJB(myPath.MyCustomBean) not used by any EJBs
     at org.jboss.ejb3.injection.EJBHandler.getJndiName(EJBHandler.java:216)
     at org.jboss.ejb3.injection.EJBHandler.loadFieldInjectors(EJBHandler.java:326)
     at org.jboss.ejb3.injection.EJBHandler.loadInjectors(EJBHandler.java:78)
     at org.jboss.ejb3.injection.EJBHandler.loadInjectors(EJBHandler.java:57)
     at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:651)
     at org.jboss.ejb3.EJBContainer.initializePool(EJBContainer.java:586)
     at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:518)
     at org.jboss.ejb3.SessionContainer.start(SessionContainer.java:82)
     at org.jboss.ejb3.stateless.StatelessContainer.start(StatelessContainer.java:80)
     ... 126 more

  • 7. Re: InitialContext()
    Dornus Novice

    My setup is the following

    public SomeClass{
     MyCustomBean myBean;

    SomeClass and MyCustomBean both reside in the same folder and same .ejb3 jar file.

  • 8. Re: InitialContext()
    Dornus Novice

    Hmm, if I'm calling it as @EJB MyCustomBean, then the InitialContext.lookup isn't the problem here...

    This worked with the previous release RC3.

    The only thing I can think of is my ear structure. Do I have to have everything end in .jar for this to work?
    Currently I have something like this...

    - MyTest.ejb3 (EJB3 beans)
    - MyTest.par (Entity beans)
    - MyTest.jar (Regular beans
    - MyTest.war (Jsp/Servlets)

  • 9. Re: InitialContext()
    Bill Burke Master

    Don't be mad but you need to learn EJB 101. You don't reference bean classes directly. YOu reference their interfaces:

    public class MyCustomBean implements MyCustom {

    public SomeClass implemetns ... {

    @EJB MyCustom

  • 10. Re: InitialContext()
    Dornus Novice

    Yeah I usually do call it by the interface name.

    However in one of the tutorials I downloaded I noticed the lookup was called using the bean directly

    Instead of the interface.

    So i assumed it changed between versions.

    I still have it as
    @EJB MyBeanInterface

    but I changed lookups to "MyBeanDirectly/local"

    However I'm still getting an exception with the @EJB tag.

  • 11. Re: InitialContext()
    Dornus Novice

    The example I saw it on was here:

     InitialContext ctx = new InitialContext();
     Calculator calculator = (Calculator) ctx.lookup("CalculatorBean/remote");

    And CalculatorBean is as follows
    public class CalculatorBean implements CalculatorRemote, CalculatorLocal

  • 12. Re: InitialContext()
    Dornus Novice

    Hmm, odd it seems as though you do use the beanname convention to get it working


  • 13. Re: InitialContext()
    Ralf Quebbemann Newbie

    Yep, that's it.
    I had the same problem. It worked when I deployed the ejb3 jar file standalone, but it didn't work when I used an ear.

    So I followed your recommendations and found out, that the exact name of the session bean deployed within an ear is:



  • 14. Re: InitialContext()
    Ralf Quebbemann Newbie

    I was just thinking it that's really the way it's supposed to be? The client should and must not know about the filename of the ear. I consider this as a workaround.