4 Replies Latest reply on Dec 20, 2004 4:50 PM by Francis simard

    Scoped beans & Remote classloader issue

    cruinne Newbie


      In a JBoss 3.2.4 server, I have deployed several enterprise javabeans (each as a separate .jar, not in an .ear bundle). These beans are completely self-contained, as they include all their needed dependencies inside the jar files (and have a reference to them in the Class-Path entry in their MANIFEST.MF).

      The problem shows when I want these beans to be scoped, this is, to have their own classloader inside JBoss and not use the unified classloader so that each bean does not see the others' classes, something very important for my software architecture. For this, I set in the jboss.xml file of each of my ejb .jar files the following:

       <loader-repository>some.dot.com:loader=[some unique name]</loader-repository>

      And in the jboss-service.xml file I enable CallByValue for the EJB Deployer.

      ...and with this I get the results I expected. The problem is, I need some of my ejbs to return to the web tier classes of which this web tier only has an interface (not the real implementations, which may vary). This means that, when the web tier receives the data, it should ask JBoss for the concrete implementation of the class via Remote Class Loading. For this, I have set in jboss-service.xml:

       <mbean code="org.jboss.web.WebService"
       <attribute name="Port">8083</attribute>
       <attribute name="DownloadServerClasses">true</attribute>
       <attribute name="Host">${jboss.bind.address}</attribute>
       <attribute name="BindAddress">${jboss.bind.address}</attribute>

      Which made remote classloading work perfectly before I scoped my ejbs, and which now simply makes JBoss return a ClassNotFoundException when tomcat asks for the implementation class.

      I supose this means that the remote classloader cannot access the ejbs' concrete classloaders now they're not unified but... Can this behaviour be changed? Can I configure it some way so that I can do remote classloading with scoped beans?



        • 1. Re: Scoped beans & Remote classloader issue
          Scott Stark Master

          You need to redundantly include the classes in question in the web layer, and scope its deployment as well. I will have to look into why the remote class loading would break with a scoped ejb deployment.

          • 2. Re: Scoped beans & Remote classloader issue
            Lea Thurman Newbie

            Hi cruinne,

            I may have misunderstood your question, so if I have I apologise.

            Is it not just a case of treating the EJB call from the web tier as you would a normal EJB client i.e it just needs access to the Remote and Home classes, the implementation is not shipped.

            We current have a situation (with 3.0.6!) with mutliple scope ears and a call from the web tier. In our case we just supplied to the container a jar of the home and remotes. Only the ejb container has visibility of the impls.

            Hot-deploy still work as we employ a facade pattern which means we rarely need to change to EJB the web tier calls.

            When we use the embedded web tier we just put this jar into server/default/lib.


            • 3. Re: Scoped beans & Remote classloader issue
              Sylvain Laurent Newbie

              I just encountered a similar situation. For me the ClassNotFoundException is cause by a "no security manager: RMI class loader disabled" problem.

              Actually, with callByValue, everything works fine because the client doesn't need to download any class. But with CallByValue enabled, the client misses the org.jboss.invocation.MarshallingInvokerInterceptor class and so attempts to download it.

              I think org.jboss.invocation.MarshallingInvokerInterceptor should be included in the jbossall-client.jar no?

              • 4. Re: Scoped beans & Remote classloader issue
                Francis simard Newbie

                I have the same problem and the same message "For me the ClassNotFoundException is cause by a "no security manager: RMI class loader disabled" problem."

                Si someone fix this issue.