4 Replies Latest reply on Apr 24, 2003 5:33 AM by betaniik

    Referencing EJBs in a JAR file from a WAR

    betaniik

      Not sure how to access a session EJB which has been deployed in a separate JAR file from a WAR.

      My files look like this:

      web.xml
      ======
      <web-app>
      ...
      <ejb-ref>
      <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
      <ejb-ref-type>Session</ejb-ref-type>
      foo.bar.MyEJBHome
      foo.bar.MyEJB
      </ejb-ref>
      ...
      </web-app>

      jboss-web.xml
      ==========
      <jboss-web>
      ...
      <ejb-ref>
      <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
      <jndi-name>MyJNDI</jndi-name>
      </ejb-ref>
      ...
      </jboss-web>

      (Where the jndi-name MyJNDI is that of the bean in the JAR.)

      This results in

      javax.naming.NamingException: ejb-ref: ejb/MyEJB, no ejb-link match, use jndi-name in jboss-web.xml

      during the deployment of the WAR. No difference even if I wrap the JAR and the WAR in an EAR file.


      Removing the <ejb-ref> tag in web.xml allows the deployment to go ahead, but then the context lookup to java:comp/env/ejb/MyEJB fails. ejb not bound, it says.


      I've tried to do a context lookup on the JNDI name of the bean directly. This works, but only on startup of JBoss. Any subsequent redeploy results in a ClassCastException on lookup, such as:

      Couldn't cast class $Proxy62 into interface foo.bar.MyEJBHome

      Despite the fact that subsequent tests reveal that what is returned is indeed a foo.bar.MyEJBHome.


      So this leads me to suspect that I'm not supposed to be doing a direct lookup anyway.


      Using JBoss 3.0.4. Any help appreciated.

      B

        • 1. Re: Referencing EJBs in a JAR file from a WAR

          The error message suggests it is not
          parsing the ejb-ref in jboss-web.xml

          Do you have it in the correct place?

          If you redeploy an ejb interface in an ejb jar
          while a war is still holding a reference to the
          class, it will classcast. The war is using
          the old version of the class from the previous
          ejb deployment.

          Regards,
          Adrian

          • 2. Re: Referencing EJBs in a JAR file from a WAR
            betaniik

            No, apparently I didn't. The ejb-ref is now working.

            Unfortunately, the redeploy problem is still there, and it bears a striking resemblance to this:

            http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t= ClassCastException still occurs even if I redeploy both JAR and WAR files. I've tried wrapping them up in an EAR to see if that helps things, but no luck.

            Also, I removed the Home and Remote interface classes from the WAR file. I suspected that this would prevent my application working even on startup, but miraculously JBoss finds the classes.

            Now there is only ever one instance of the classes (in the JAR), but this ClassCastException remains.

            Tried deploying on 3.0.7 instead, no luck either.

            Any ideas?

            B

            • 3. Re: Referencing EJBs in a JAR file from a WAR

              Are you using jdk 1.4?

              Is there a JBossRMIClassloader in run.jar?

              I think the 3.0.7 is compiled with 1.3 so it
              doesn't include that class.

              It has a workaround for some ill conceived caching
              in the RMI classloader that appear in 1.4

              What this actually means is that your naming is
              going over RMI, probably because you have
              a jndi.properties in one of your deployments.

              Remove the jndi.properties.

              Regards,
              Adrian

              • 4. Re: Referencing EJBs in a JAR file from a WAR
                betaniik

                Hallelujah! That did the trick.

                Did figure that something wrong was going on with caching, but wasn't sure how to fix it.

                There is strangely enough also a thread which proposes to add a jndi.properties file to force lookup over RMI. For some reason, this gets rid of a similar problem for others.

                B