3 Replies Latest reply on Jun 18, 2007 3:20 PM by Gavin King

    JNDI Problem ?

    Christophe Arnaud Newbie

      Hi.

      I have the following problem...

      I'm using 2 session beans, with same class name, but different packages :

      package evenium.ejb3.test.example1;
      
      ...
      
      @Stateful
      @Name("test.example1.search")
      @Scope(ScopeType.SESSION)
      public class SearchAction implements Search
      {
       ...
      }
      


      package evenium.ejb3.test.example2;
      
      ...
      
      @Stateful
      @Name("test.example2.search")
      @Scope(ScopeType.SESSION)
      public class SearchAction implements Search
      {
       ...
      }
      


      When I call one of them from a view, I get something like :


      GRAVE: Error Rendering View[/example2/search.xhtml]
      org.jboss.seam.InstantiationException: Could not instantiate Seam component: test.example2.search
      ...
      Caused by: javax.naming.NameNotFoundException: local not bound
      


      During JBoss AS startup, the two components seem to be loaded :

      
      INFO [Component] Component: test.example1.search, scope: SESSION, type: STATEFUL_SESSION_BEAN, class: evenium.ejb3.test.example1.SearchAction, JNDI: Global_EAR_Project/SearchAction/local
      
      ...
      
      INFO [Component] Component: test.example2.search, scope: SESSION, type: STATEFUL_SESSION_BEAN, class: evenium.ejb3.test.example2.SearchAction, JNDI: Global_EAR_Project/SearchAction/local
      
      


      Except they have identical JNDI names...

      If a rename one of the two beans (let's say : SearchActionX), everything runs fine... I imagine I could also use @JndiName for every bean - somehow tedious.

      In my components.xml I have :

      <core:init jndi-pattern="PhaseII_Global_EAR_Project/#{ejbName}/local" debug="true"/>


      Shouldn't #{ejbName} be replaced by qualified class name ?



        • 1. Re: JNDI Problem ?
          Gavin King Master

          No, its an EJB name, not a class name. Check the EJB spec.

          All you need to do is specify an EJB name explicitly using @Stateful(name=...).

          • 2. Re: JNDI Problem ?
            Christophe Arnaud Newbie

            Thanks for the reply...

            I quickly had a look at the spec, where I found :

            The name annotation element defaults to the unqualified name of the bean class. The name?whether explicitly specified or defaulted?must be unique within the ejb-jar.


            Plus, I actually had an error (i haven't noticed it) thrown by the EJB container at the beginning of the deployement, stating :

            jboss.j2ee:ear=Global_EAR_Project.ear,jar=EJB3_Action_Test.jar,name=SearchAction,service=EJB3 + is already registered


            So it's very consistent with what you said.

            Adding @Stateful(name="test/example1/search") and @Stateful(name="test/example2/search") where required, solved the problem.

            Thanks for having made things clearer to me.



            Now, just one more question I'd like to have your opinion on...

            For large application developpement with Seam, you finally end up with beans that look like :

            package com.my.package;
            
            @Stateful(name="com/my/package")
            @Name("com.my.package.MyBean")
            public class MyBeanAction implements MyBean
            ...


            Don't you think there is too much redundancy ?

            (Seam turned me into a loafer)



            • 3. Re: JNDI Problem ?
              Gavin King Master

              Yes, its definitely too redundant. Web Beans will default component names, and we may well decide to default to a qualified name (though thats by no means certain). Unfortunately we're stuck with the EJB name default.

              But notice that EJB names are only unique in the ejb-jar. So for a truly large app you would usually package things into multiple ejb-jars.

              Seam/Web Beans names are different, they need to be unique in the whole ear, and so I think there's an even stronger argument for defaulting to a qualified name.