6 Replies Latest reply on Mar 19, 2007 10:31 PM by Scott Stark

    Missing EAR/WAR Isolation

    Jason Greene Master

      It looks like we are missing EAR isolation in the trunk ear deployer. This results in several WS TCK failures:

      http://jira.jboss.com/jira/browse/JBWS-1581

      After looking at the code, it appears the intention is that EARStructure should be creating an isolated load repository config that is used by the ServiceClassLoaderDeployer. Any reason this has not been implemented yet?

      Another reason for this failure is that WAR isolation is effectively disabled as well (WarClassLoadingDeployer is commented out). Why?

      -Jason

        • 1. Re: Missing EAR/WAR Isolation
          Scott Stark Master

          The EARStructure defines what the deployable content is in the ear along with what its classpath is. It does not define scoping. This should be coming from the metadata of the AppParsingDeployer (jboss-app.xml, deployer isolation property) that is passed to the ServiceClassLoaderDeployer which should be creating the scoped ULR. I'll have to check if this is wired up correctly. I'm working on the jboss5 testsuite so I'll look at the existing ear isolation tests today.

          On the first port of the war deployer, jbossweb didn't have a mechanism to accept a class loader so it was commented out. It should be creating a scoped class loader by default though, but its probably still an implementation detail of the webcontainer. It does need to be pulled out so its available at the DeploymentUnit level. I assume that is what you are looking for?

          • 2. Re: Missing EAR/WAR Isolation
            Jason Greene Master

             

            "scott.stark@jboss.org" wrote:
            The EARStructure defines what the deployable content is in the ear along with what its classpath is. It does not define scoping. This should be coming from the metadata of the AppParsingDeployer (jboss-app.xml, deployer isolation property) that is passed to the ServiceClassLoaderDeployer which should be creating the scoped ULR.


            Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml.

            The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it?

            I'll have to check if this is wired up correctly. I'm working on the jboss5 testsuite so I'll look at the existing ear isolation tests today.


            Great thanks.

            -Jason

            • 3. Re: Missing EAR/WAR Isolation
              Jason Greene Master



              On the first port of the war deployer, jbossweb didn't have a mechanism to accept a class loader so it was commented out. It should be creating a scoped class loader by default though, but its probably still an implementation detail of the webcontainer. It does need to be pulled out so its available at the DeploymentUnit level. I assume that is what you are looking for?


              Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments.

              That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs.

              • 4. Re: Missing EAR/WAR Isolation
                Scott Stark Master

                 

                "jason.greene@jboss.com" wrote:

                Ah I see, I was confused since currently, EARStructure is parsing jboss-app.xml.

                The issue is the lack of a default if there is no jboss-app.xml (or no loader-repository-config). In the past we had a global isolation setting directly on the ear deployer. So I assumed we are keeping that. I take it we are moving away from it?

                No, the global setting should be coming in from the AppParsingDeployer as a default. Its just not been ported over. I created this issue for that:
                http://jira.jboss.com/jira/browse/JBAS-4214

                "jason.greene@jboss.com" wrote:

                Ah I see. Yes, the issue is that the WS deployer has to inspect every war (WS or not) by loading all servlet classes (and related WS classes if it is in fact a WS deployment). If the DeploymentUnit CL is not isolated, there is the possibility of a conflict with multiple deployments.

                That said, fixing EAR isolation will resolve the WS TCK issues, since they separate the client and server side components in individual EARs.

                I created this issue for the externalization of the war class loader.
                http://jira.jboss.com/jira/browse/JBAS-4215



                • 5. Re: Missing EAR/WAR Isolation
                  Thomas Diesler Master

                  This should be fixed

                  [tdiesler@tdvaio trunk]$ svn log -v -r61470
                  ------------------------------------------------------------------------
                  r61470 | thomas.diesler@jboss.com | 2007-03-19 23:19:11 +0100 (Mon, 19 Mar 2007) | 1 line
                  Changed paths:
                   M /trunk/server/src/main/org/jboss/deployment/AppParsingDeployer.java
                   M /trunk/server/src/main/org/jboss/deployment/JBossAppParsingDeployer.java
                   M /trunk/server/src/main/org/jboss/deployment/JBossApplicationObjectFactory.java
                   M /trunk/system-jmx/src/main/org/jboss/system/deployers/ServiceClassLoaderDeployer.java
                  
                  Fix EAR scoping with <loader-repository>
                  



                  • 6. Re: Missing EAR/WAR Isolation
                    Scott Stark Master

                    I have further added the isolation and callByValue flags to the ear and ejb deployers:

                    ear-deployer-beans.xml:
                     <bean name="JBossAppParsingDeployer" class="org.jboss.deployment.JBossAppParsingDeployer">
                    ...
                     <!-- A flag indicating if ear deployments should have their own scoped
                     class loader to isolate their classes from other deployments.
                     -->
                     <property name="isolated">true</property>
                     <!-- A flag indicating if the ear components should have in VM call
                     optimization disabled.
                     -->
                     <property name="callByValue">true</property>
                     </bean>
                    
                    ejb-deployer-beans.xml:
                     <bean name="EJB2xDeployer" class="org.jboss.ejb.deployers.EjbDeployer">
                    
                     <!-- A flag indicating if the ear components should have in VM call
                     optimization disabled.
                     -->
                     <property name="callByValue">false</property>
                     </bean>
                    


                    Your change would pickup deployments with explicit jboss-app.xml isolation, now apps without any isolation config will pickup the ear default as well.