2 Replies Latest reply on Nov 15, 2005 8:57 PM by Adrian Brock

    Configuring jbossweb to handle local EJB calls from war to j

    Michael Kerry Newbie

      Hi,

      I have run into the same problem discussed in thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71090. So as not to risk the ire of adrian, I have not hijacked that thread; but I was unsure to which forum to direct this. My apologies if my aim is bad.

      To summarize the problem in that thread, I have a single ear file containing a war file and a jar file. The war contains a servlet that makes EJB calls to session beans in the jar file. I have found that I am unable to create a local interface to my session beans in the servlet; it fails with "Invalid invocation..." EJBExceptions. However, if I change them to remote EJB interfaces, everything works great. Also, when I change the jbossweb values for Java2ClassLoadingCompliance and UseJBossWebLoader from the default false values to true, the local calls work fine (this is my current solution, taken from the above thread). Details follow at the bottom of this post, to avoid clutter.

      My question is slightly different from in the above thread.

      1. Assuming that changing the Java2ClassLoadingCompliance and UseJBossWebLoader is the correct solution to the problem, is there a way to achieve this behavior on an application basis? That is, if I am forced to deploy my ear into a JBoss4.0.3SP1 installation which has not changed these values (the default config), and I am not permitted to change them just for my app, can my app override them somehow to make it work for me?

      2. Having read the classloading wiki pages (ClassLoadingConfiguration and JBossClassLoadingUseCases), it is likely that I simply do not fully grok this wizardry. Is my configuration below just plain incorrect? Could my war or jar files be incorrectly packaged? Can it truly be that this is the only way to get local EJB calls to work within an ear in JBoss4.0.3SP1 (this is hard for me to believe, but it is what I am experiencing...)?

      Thanks for your time.

      Details:

      JBoss4.0.3SP1
      Windows XP


      (Hopefully) relevant contents of various config files:

      deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml (these values cause the local EJB creates to fail -- if I set them to true, it all works; so this is the behavior I would like to override, assuming this is a correct solution to the problem):

      <!-- Get the flag indicating if the normal Java2 parent first class
       loading model should be used over the servlet 2.3 web container first
       model.
       -->
       <attribute name="Java2ClassLoadingCompliance">false</attribute>
       <!-- A flag indicating if the JBoss Loader should be used. This loader
       uses a unified class loader as the class loader rather than the tomca
      t
       specific class loader.
       The default is false to ensure that wars have isolated class loading
       for duplicate jars and jsp files.
       -->
       <attribute name="UseJBossWebLoader">false</attribute>


      deploy/ear-deployer.xml:
      <!-- A flag indicating if ear deployments should have their own scoped
       class loader to isolate their classes from other deployments.
       -->
       <attribute name="Isolated">true</attribute>
       <!-- A flag indicating if the ear components should have in VM call
       optimization disabled.
       -->
       <attribute name="CallByValue">true</attribute>


      deploy/naming-service.xml:
      <!-- The call by value mode. true if all lookups are unmarshalled using
       the caller's TCL, false if in VM lookups return the value by reference.
       -->
       <attribute name="CallByValue">true</attribute>


      In my ear file (META-INF/jboss-app.xml):
      <jboss-app>
       <loader-repository>
       my_company.com:loader=my_app.ear
       <loader-repository-config>
       java2ParentDelegation=true
       </loader-repository-config>
       </loader-repository>
      </jboss-app>



      Lastly, the exception I get attempting to create a local interface to my session bean. The line in my code that is referenced in the trace is simply a call to the create() method off of a home interface. The exception is:


      09:15:15,265 ERROR [LogInterceptor] EJBException in method: public abstract com.
      collabraspace.cserver.interfaces.CampusServiceLocal com.collabraspace.cserver.in
      terfaces.CampusServiceLocalHome.create() throws javax.ejb.CreateException:
      javax.ejb.EJBException: Invalid invocation, check your deployment packaging, met
      hod=public abstract com.collabraspace.cserver.interfaces.CampusServiceLocal com.
      collabraspace.cserver.interfaces.CampusServiceLocalHome.create() throws javax.ej
      b.CreateException
       at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invokeHo
      me(StatelessSessionContainer.java:161)
       at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invo
      keHome(CachedConnectionInterceptor.java:180)
       at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invokeHome(
      StatelessSessionInstanceInterceptor.java:83)
       at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractIntercep
      tor.java:90)
       at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValida
      tionInterceptor.java:41)
       at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInte
      rceptor.java:110)
       at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercep
      torCMT.java:335)
       at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.ja
      va:146)
       at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityIntercep
      tor.java:130)
       at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:1
      21)
       at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyF
      actoryFinderInterceptor.java:93)
       at org.jboss.ejb.SessionContainer.internalInvokeHome(SessionContainer.ja
      va:613)
       at org.jboss.ejb.Container.invoke(Container.java:894)
       at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLoca
      lProxyFactory.java:344)
       at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java
      :118)
       at $Proxy172.create(Unknown Source)
       at com.collabraspace.csuite.server.i9n.ejb.CSuiteAdminEJBTest.setUp(CSui
      teAdminEJBTest.java:194)
       at junit.framework.TestCase.runBare(TestCase.java:125)
       at org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(Abstr
      actCactusTestCase.java:153)
       at org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(Abstra
      ctWebTestCaller.java:119)
       at org.apache.cactus.internal.server.AbstractWebTestController.handleReq
      uest_aroundBody0(AbstractWebTestController.java:93)
       at org.apache.cactus.internal.server.AbstractWebTestController.handleReq
      uest_aroundBody1$advice(AbstractWebTestController.java:224)
       at org.apache.cactus.internal.server.AbstractWebTestController.handleReq
      uest(AbstractWebTestController.java)
       at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(Ser
      vletTestRedirector.java:101)
       at org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$adv
      ice(ServletTestRedirector.java:224)
       at org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedi
      rector.java)
       at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(Serv
      letTestRedirector.java:72)
       at org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advi
      ce(ServletTestRedirector.java:224)
       at org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedir
      ector.java)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
      icationFilterChain.java:252)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
      ilterChain.java:173)
       at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
      lter.java:81)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
      icationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
      ilterChain.java:173)
       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
      alve.java:213)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
      alve.java:178)
       at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrinc
      ipalValve.java:39)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
      yAssociationValve.java:159)
       at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
      torBase.java:407)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
      e.java:59)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
      ava:126)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
      ava:105)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
      ve.java:107)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
      a:148)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
      :856)
       at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
      ssConnection(Http11Protocol.java:744)
       at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
      int.java:527)
       at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWor
      kerThread.java:112)
       at java.lang.Thread.run(Thread.java:534)


        • 1. Re: Configuring jbossweb to handle local EJB calls from war
          Adrian Brock Master

          Yet another variation of the "not read the spec FAQ".
          Compounded by the "I have some config that works, but I don't understand why
          this other config doesn't" comment.

          Local EJBs are never invoked call-by-value, regardless of any configuration you might make.


          at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java
          :118)


          Solution: Don't deploy your classes twice in different classloaders
          and expect the Java type system to understand it.

          Solution 2: Don't create two different classloaders (i.e. use the config you say works
          one classloader for whole ear not some satellite for the war)

          Solution 3: Read some documentation about classloading and the java type system.
          e.g. Chapter 2 of the admin docs.

          • 2. Re: Configuring jbossweb to handle local EJB calls from war
            Adrian Brock Master

            I told Scott that changing the UseJBossWebClassLoader to false
            would cause no end of FAQs.

            The java classloading system is just not comprehensible to most users
            and it is compounded with the diametrically opposite servlet/war classloading rules.