7 Replies Latest reply on Jun 3, 2004 12:06 PM by jae

    can't connect to Bean in other EAR

    Mark Britten Newbie


      I have a been in another EAR that has a webpage JSP client that connects to it.

      If I copy the Bean files and webpage JSP client to another package I cannot access it as I get the below error.

      javax.ejb.EJBException: Invalid invocation, check your deployment packaging, method=public abstract com.upstreamsystems.
      mip.clubs.ClubManager com.upstreamsystems.mip.clubs.ClubManagerHome.create() throws java.rmi.RemoteException,javax.ejb.CreateException
      at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invokeHome(StatelessSessionContainer.java:597) ...

      The only difference in the EAR files is that I removed from the client EAR the info from the ejb-jar.xml and the jboss.xml so as not to implement the bean there. Is this correct?

      I am using a different classloader for each EAR if this is of any significance.

      I am using basic code to call from in the EAR and from the other EAR

      Class clubMgrHomeClass = com.upstreamsystems.mip.clubs.ClubManagerHome.class;

      // Create env.
      Hashtable env = new Hashtable();

      InitialContext jndiCtx=new InitialContext(env);
      String clubMgrJndiName = "com/upstreamsystems/mip/clubs/ClubManager";
      try {
      ClubManagerHome clubMgrHome = (ClubManagerHome) PortableRemoteObject.narrow(jndiCtx.lookup(clubMgrJndiName), clubMgrHomeClass);
      ClubManager clubMgr = clubMgrHome.create();

      Anyone have any ideas why I cannot call the EJB from the other EAR?



        • 1. Re: can't connect to Bean in other EAR
          jae Master

          if i understand what you're asking, you're saying that you have two ears (using seperate class loaders through a loader repository) and you wish for EAR1 to communicate w/ an ejb in EAR2.

          if this is correct, then you want to read this:


          if this isn't what you were looing for, could you pls give a clearer explination of what you would like to accomplish.

          • 2. Re: can't connect to Bean in other EAR
            Mark Britten Newbie


            To clarify:

            I have a EJB in EAR A and the same EJB in EAR B but I have removed initialisation information from EAR B so that it does not construct the EJB also. I initialise and access the EJB in EAR A with a client within EAR A. However, I cannot access this EJB in EAR A with a client inside EAR B even though I have the class files.

            Is this clearer?



            • 3. Re: can't connect to Bean in other EAR
              jae Master

              are the ears scoped? you mentioned in your first post that they are using seperate class loaders.

              • 4. Re: can't connect to Bean in other EAR
                Mark Britten Newbie


                what do you mean by scoped?


                • 5. Re: can't connect to Bean in other EAR
                  jae Master

                  did you specify a loader-repository inside the jboss.xml file that is packaged inside the ear? that's the only way you could have both ears using seperate class loaders.

                  i'd still recommend reading the wiki page and adjusting your packaging as described, you'll be better off in the long run.

                  • 6. Re: can't connect to Bean in other EAR
                    Mark Britten Newbie

                    Hi Jae,

                    I understand what you are saying, but this is not convenient to have my EJB classes in the JBoss lib because of the redeployment issue.

                    I would like to find a way without having to resort to this.



                    • 7. Re: can't connect to Bean in other EAR
                      jae Master

                      you don't have to deploy the classes into the 'lib' directory. everything can be deployed into the 'deploy' directory.

                      the only time you can't hot-deploy in this situation is if the ejb interface changes. if all you do is change business logic inside the ejb, then you can hot deploy the ear w/o issue. if you change the interfaces, then you need to restart the server in order for the changes to be picked up.

                      what you should end up having is the following:

                      - a jar w/ all the ejb interfaces in addition to any additional classes that interface needs to operate (ie, if one of your methods returns an object of class type Foo, then Foo.class needs to be packaged in the same jar as the ejb interfaces).

                      - EAR1 w/ all necessary classes it needs to operate minus those contained in the jar

                      - EAR2 w/ all the necessary classes minus those included in the jar.

                      provided the ejb interface does not change (or any of the other classes contained inside the jar) you can hot deploy EAR1 and/or EAR2 w/o problem. if the classes inside the jar do change, then you need the server restart.

                      i highly recommend spending the 10 bux (if you haven't done so already) and getting the jboss admin book. chapter 2 talks all about this (see the classloader section).