7 Replies Latest reply on Oct 17, 2013 1:52 AM by sfcoy

    EJB2 session bean deployment issues while migrating from jboss 4.3 to 7

    prashamsjain

      Hello Team,

       

      I am currently trying to migrate a application from Jboss 4.3 to Jboss AS 7. While deploying a ejb.ear in jboss 7 i am getting the exception as attached.

       

      Directory Structure of ear

      testejb.ear

           -    testejb1.jar

           -     supporting.jar

      testfileejb.ear

           -     testfileejb.jar

           -      supporting.jar

       

      Message driven bean in testejb uses session bean testfileejb as ejb external ref. The jndi-name of session bean is of "java:global" but it seems that server is looking at "java:comp".

       

      Please provide your inputs on this issue.

       

      My jboss.xml contains

      <message-driven>

           <ejb-name>FileDelivery</ejb-name>

           ...

           <ejb-ref>

                <ejb-ref-name>FileService</ejb-ref-name>

                <jndi-name>java:global/FileService</jndi-name>

           </ejb-ref>

           ...

      </message-driven>

       

      My ejb-jar.xml contains

      <message-driven>

           <ejb-name>FileDelivery</ejb-name>

           ...

           <ejb-ref>

                <ejb-ref-name>FileService</ejb-ref-name>

                <ejb-ref-type>Session</ejb-ref-type>

                <home>com.myapp.FileServiceHome</home>

                <remote>com.myapp.FileServiceRemote</remote>

           </ejb-ref>

      </message-driven>

        • 1. Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
          sfcoy

          testejb.ear needs to provide a copy of all of the home and businessinterface classes that it references from testfileejb.ear.

           

          Typically, these classes would be made available in testfileejb-api.jar in the lib directory of testejb.ear.

           

          JBossAS7.x/WildFly has (mostly) spec compliant class loading by default, meaning classes in one ear are not normally visible to classes in another ear. Earlier versions of JBossAS had to be configured to use spec compliant class loading.

           

          There are other ways of accomplishing the same thing, but that would require you to read and understand most of Chapter EE.8 "Application Assembly and Deployment" of the "Java™ Platform, Enterprise Edition (Java EE) Specification, v6", and/or https://docs.jboss.org/author/display/AS72/Class+Loading+in+AS7.

          • 2. Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
            prashamsjain

            Hi Stephen,

             

            Thanks for you quick response. I have already added the testfileejb-api.jar in the lib directory of testejb.ear but still facing the issue.

             

            In testfileejb.ear, I am using java:global/FileService as a jndi name. Also I am using the same to reference it from testejb.ear, but it seems server is searching for "java:comp/env/FileService".

            • 3. Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
              sfcoy

              Please attach the complete server.log.

               

              I suspect that there is no actual object at java:global/FileService.

              • 4. Re: Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
                sfcoy

                Sorry, I've just noticed that you're using jboss.xml. This has now been replaced by jboss-ejb3.xml which you must use now.

                 

                From what I can see from your log, your ejb-ref will then look something like:

                     <ejb-ref>
                          <ejb-ref-name>FileService</ejb-ref-name>
                          <lookup-name>java:jboss/exported/filemanager-as-ear-3.1.0.0/filemanager-as-ejb-3.1.0.0/FilemanagerService!com.myapp.infra.filemanager.appservice.ejb.FilemanagerServiceHome</lookup-name>
                     </ejb-ref>
                

                 

                You code does indeed lookup java:comp/env/FileService. The ejb-ref decouples your java code from the real JNDI name of the EJB, which gets linked for you via the jboss-ejb3.xml file. You will see this pattern replicated for all the different *-ref-name elements. There is always an implicit java:comp/env prefix, unless a fully qualified name is provided, such as java:app/FileService (an ejb-ref-name, not a lookup-name). This last bit is new in JavaEE 6.

                • 5. Re: Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
                  prashamsjain

                  Hi Stephen,

                   

                  Thanks for your response. We use xdoclet ejb2.1 spec which generates jboss.xml. But since it is now ignored by Jboss as 7 do I need to migrate first from ejb2.1 to ejb 3 ?

                  • 6. Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
                    sfcoy

                    Strictly speaking it is not necessary to migrate to EJB3. However, you will likely find life much easier in the future if you bite the bullet and do it now. You will probably find it consists mainly of removing stuff (such as home interfaces). This assumes that you do not have any CMP entity beans.

                     

                    If you need to defer this then I suggest building your jboss-ejb3.xml file using the generated jboss.xml as a basis. Most of it will be the same.

                    • 7. Re: Re: EJB2 session bean deployment issues while migrating from jboss 4.3 to 7
                      sfcoy

                      Remove the fourth line containing:

                       <lookup-name>java:global/EmailService</lookup-name>
                      

                       

                      You could change it to:

                      <mapped-name>java:global/EmailService</mapped-name>
                      

                      but it may be easier to use the container generated defaults for the time being.

                      1 of 1 people found this helpful