1 2 Previous Next 23 Replies Latest reply on Oct 21, 2008 4:15 AM by istudens

    Testing Bootstrap Dependencies

    brian.stansberry

      Discussion related to https://jira.jboss.org/jira/browse/JBAS-5349, which I believe Ivo Studensky is going to address.


      I was thinking a bit about issues with testing this kind of thing; take this for what it's worth.

      A problem such a test would have to solve would be ensuring that the test deployments are deployed very early in the cycle, i.e. before anything else in deploy/. Otherwise a missing dependency on something that just happens to be deployed earlier would go undetected.

      To get the test deployment to deploy early, you need to understand how the MainDeployer orders deployments. This is determined via the conf/deployers.xml file, the "topContextComparator" bean:

      <!-- use legacy ordering -->
       <bean name="topContextComparator">
       <constructor factoryClass="org.jboss.system.deployers.LegacyDeploymentContextComparator" factoryMethod="getInstance"/>
       </bean>


      The LegacyDeploymentContextComparator class is found in the AS's 'system' module. This snippet shows how things are ordered:

      /** Legacy orders */
       private static Map<String, Integer> legacyOrder;
      
       static
       {
       legacyOrder = new HashMap<String, Integer>();
       legacyOrder.put(".deployer", 50);
       legacyOrder.put("-deployer.xml", 50);
       legacyOrder.put(".aop", 100);
       legacyOrder.put("-aop.xml", 100);
       legacyOrder.put(".sar", 150);
       legacyOrder.put("-service.xml", 150);
       legacyOrder.put(".beans", 200);
       legacyOrder.put("-jboss-beans.xml", 200);
       legacyOrder.put(".rar", 250);
       legacyOrder.put("-ds.xml", 300);
       legacyOrder.put(".har", 350);
       legacyOrder.put(".jar", 400);
       legacyOrder.put(".ejb3", 400);
       legacyOrder.put(".par", 400);
       legacyOrder.put(".war", 500);
       legacyOrder.put(".wsr", 600);
       legacyOrder.put(".ear", 650);
       legacyOrder.put(".jar", 700);
       legacyOrder.put(".zip", 750);
       legacyOrder.put(".bsh", 800);
       legacyOrder.put(".last", 900);
       }


      In case of a tie, deployments are ordered based on the string ordering of their simple name.

      So, an A.sar would deploy early, but after any .aop or -aop.xml.

        • 1. Re: Testing Bootstrap Dependencies
          istudens

          Thanks for your advice. It was very helpful for me.


          I want to share my first ideas about the implementation. I am not sure about package which the test should be in and other things.

          I have made a simple SAR which is responsible for deployment of testing modules like JARs, EARs, WARs and so on. The code snippet of the SAR:

          package org.jboss.test.deployers_jbas5349.sar;
          
          public class DeploymentDependencyTest
           extends ServiceMBeanSupport
           implements DeploymentDependencyTestMBean
          {
           // Constants -----------------------------------------------------
           public final static String DEPLOYER_NAME = "jboss.system:service=MainDeployer";
          
           // Attributes -----------------------------------------------------
           protected String deployModule;
          
           @Override
           protected void startService() throws Exception
           {
           log.debug("DeploymentDependencyTest's SAR is starting");
          
           deployModule = System.getProperty("deployment.dependency.test.module");
          
           if (deployModule != null)
           {
           log.debug("deploying of " + deployModule);
           deploy(deployModule);
           } else {
           // what should I do?
           }
          
           log.debug("DeploymentDependencyTest's SAR is started");
           }
          
           @Override
           protected void stopService() throws Exception
           {
           log.debug("DeploymentDependencyTest's SAR is stopping");
          
           if (deployModule != null)
           {
           log.debug("un-deploying of " + deployModule);
           undeploy(deployModule);
           }
          
           log.debug("DeploymentDependencyTest's SAR is stopped");
           }
          
           ...
          
           protected void deploy(String name) throws Exception
           {
           if (Boolean.getBoolean("jbosstest.nodeploy") == true)
           {
           log.debug("Skipping deployment of: " + name);
           return;
           }
          
           URL deployURL = getDeployURL(name);
           log.debug("Deploying " + name + ", url=" + deployURL);
           invoke(getDeployerName(),
           "deploy",
           new Object[]{deployURL},
           new String[]{"java.net.URL"});
           }
          
           ...
          }


          The SAR is built inside testsuite/imports/sections/deployers.xml:
          <!-- JBAS-5349 SAR -->
           <jar destfile="${build.lib}/Aaadeploymentdependency-jbas5349.sar">
           <fileset dir="${build.resources}/deployers/jbas5349">
           <include name="**/*"/>
           </fileset>
           <fileset dir="${build.classes}">
           <include name="org/jboss/test/deployers_jbas5349/**"/>
           </fileset>
           </jar>


          JBoss's service XML of the SAR is located in testsuite/src/resources/deployers/jbas5349/META-INF/jboss-service.xml and is pretty simple:
          <mbean code="org.jboss.test.deployers_jbas5349.sar.DeploymentDependencyTest"
           name="org.jboss.test.deployers_jbas5349.sar.deployment.dependency.test:service=DeploymentDependencyTest">
          </mbean>


          I have not found any better way how to start JBoss server repeatedly with different jvmargs or system properties than copying the configuration of the profile "all" to the new one each time.
          So the test starts from testsuite/build.xml this way:
          <target name="deployment-dependency-tests" description="Tests deployment dependency in new JBossMC.">
           <copy file="${build.lib}/Aaadeploymentdependency-jbas5349.sar" overwrite="true" todir="${jboss.dist}/server/all/deploy/" />
           <create-profileservice-config baseconf="all" conf="deploymentdependencyserviceA"/>
           <server:config>
           <server name="deploymentdependencyserviceA">
           <jvmarg value="-Djbosstest.deploy.dir=${build.lib}" />
           <jvmarg value="-Ddeployment.dependency.test.module=deploymentdependency-ejb3-dummystateless.jar" />
           </server>
           </server:config>
           <server:start name="deploymentdependencyserviceA"/>
           <antcall target="test-deployment-dependency-mbean-state"/>
           <server:stop name="deploymentdependencyserviceA"/>
           <create-profileservice-config baseconf="all" conf="deploymentdependencyserviceB"/>
           <server:config>
           <server name="deploymentdependencyserviceB">
           <jvmarg value="-Djbosstest.deploy.dir=${build.lib}" />
           <jvmarg value="-Ddeployment.dependency.test.module=???" />
           </server>
           </server:config>
           <server:start name="deploymentdependencyserviceB"/>
           <antcall target="test-deployment-dependency-mbean-state"/>
           <server:stop name="deploymentdependencyserviceB"/>
           ...
           <delete file="${jboss.dist}/server/all/deploy/Aaadeploymentdependency-jbas5349.sar" />
           </target>


          Where antcall "test-deployment-dependency-mbean-state" runs simple test case which just checks the state of the SAR:
          package org.jboss.test.deployers_jbas5349;
          
          public class DeploymentDependencyTestCase
           extends JBossTestCase
          {
           // Constants -----------------------------------------------------
           public final static String DEPLOYMENT_DEPENDENCY_MBEAN_NAME =
           "org.jboss.test.deployers_jbas5349.sar.deployment.dependency.test:service=DeploymentDependencyTest";
           public final static int EXPECTED_MBEAN_STATE = 3;
          
           ...
          
           public void testSARStatus()
           throws Exception
           {
           getLog().debug("+++ testSARStatus");
          
           assertEquals(EXPECTED_MBEAN_STATE, checkMBeanState());
           }
          
           protected ObjectName getDeploymentDependencyMBeanName() throws MalformedObjectNameException
           {
           return new ObjectName(DEPLOYMENT_DEPENDENCY_MBEAN_NAME);
           }
          
           protected int checkMBeanState() throws Exception
           {
           if (Boolean.getBoolean("jbosstest.nodeploy") == true)
           return EXPECTED_MBEAN_STATE;
          
           Object state = invoke(getDeploymentDependencyMBeanName(), "getState", null, null);
          
           return ((Integer) state).intValue();
           }
          }



          I have written the first test module - dummy (empty) EJB3 stateless bean and run the tests with next result:
          2008-09-18 13:53:59,764 WARN [org.jboss.deployment.MainDeployer] (main) Failed to deploy: file:/home/studensky/workspace/trunk/testsuite/output/lib/deploymentdependency-ejb3-dummystateless.jar
          org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
          
          *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
          
          jboss.j2ee:ear=deploymentdependency-ejb3-dummystateless.jar,jar=deploymentdependency-ejb3-dummystateless.jar,name=DummyStateless,service=EJB3
           -> <UNKNOWN jboss.j2ee:ear=deploymentdependency-ejb3-dummystateless.jar,jar=deploymentdependency-ejb3-dummystateless.jar,name=DummyStateless,service=EJB3>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService' **}


          I hope this is one case of errors which this test should discover.
          I will continue with writing other test modules like dummy EJB3 statefull, EJB3 entity, EJB3 MDB, EJB2 stateless, EJB2 statefull, EJB2 BMP entity, EJB2 CMP entity, EJB2 MDB, simple WAR, ...

          If there are any considerations/issues about my work, don't hesitate to tell me, please.


          • 2. Re: Testing Bootstrap Dependencies
            istudens

            I have changed a few things.

            Now there is a particular test case class for each tested module and DeploymentDependencyTestCase has been changed to AbstractDeploymentDependencyTestCase:

            package org.jboss.test.deployers_jbas5349.test;
            public abstract class AbstractDeploymentDependencyTestCase
             extends JBossTestCase
            {
             ...

            package org.jboss.test.deployers_jbas5349.test;
            public class EJB3DummyStatelessTestCase
             extends AbstractDeploymentDependencyTestCase
            {
             public EJB3DummyStatelessTestCase(String name)
             {
             super(name);
             }
            }


            The tests are started from build.xml this way:
            ...
             <create-profileservice-config baseconf="all" conf="deploymentdependencyserviceA"/>
             <server:config>
             <server name="deploymentdependencyserviceA">
             <jvmarg value="-Djbosstest.deploy.dir=${build.lib}" />
             <jvmarg value="-Ddeployment.dependency.test.module=deploymentdependency-ejb3-dummystateless.jar" />
             </server>
             </server:config>
             <server:start name="deploymentdependencyserviceA"/>
             <antcall target="test-deployment-dependency-mbean-state">
             <param name="test-class-name" value="EJB3DummyStatelessTestCase"/>
             </antcall>
             <server:stop name="deploymentdependencyserviceA"/>
             <create-profileservice-config baseconf="all" conf="deploymentdependencyserviceB"/>
             <server:config>
             <server name="deploymentdependencyserviceB">
             <jvmarg value="-Djbosstest.deploy.dir=${build.lib}" />
             <jvmarg value="-Ddeployment.dependency.test.module=deploymentdependency-ejb3-dummystateful.jar" />
             </server>
             </server:config>
             <server:start name="deploymentdependencyserviceB"/>
             <antcall target="test-deployment-dependency-mbean-state">
             <param name="test-class-name" value="EJB3DummyStatefulTestCase"/>
             </antcall>
             <server:stop name="deploymentdependencyserviceB"/>
             ...


            • 3. Re: Testing Bootstrap Dependencies
              istudens

              There are 5 finished test modules.


              • EJB3 Stateless Bean - fails with dependency on 'jboss.ejb:service=EJBTimerService'
              • EJB3 Stateful Bean - fails with dependency on 'jboss.ejb:service=EJBTimerService'
              • EJB3 Entity - fails with dependency on 'jboss.jca:name=DefaultDS,service=DataSourceBinding'
              • EJB3 Message Bean - success
              • Web module (WAR) - fails with dependency on 'JBossSecurityPolicyRegistration' and 'JNDIBasedSecurityManagement'


              • 4. Re: Testing Bootstrap Dependencies
                istudens

                Note: 'fails with dependency' means, for example:

                2008-09-19 10:54:05,012 WARN [org.jboss.deployment.MainDeployer] (main) Failed to deploy: file:/home/studensky/workspace/trunk/testsuite/output/lib/deploymentdependency-ejb3-dummystateless.jar
                org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
                
                *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
                
                jboss.j2ee:ear=deploymentdependency-ejb3-dummystateless.jar,jar=deploymentdependency-ejb3-dummystateless.jar,name=DummyStateless,service=EJB3
                 -> <UNKNOWN jboss.j2ee:ear=deploymentdependency-ejb3-dummystateless.jar,jar=deploymentdependency-ejb3-dummystateless.jar,name=DummyStateless,service=EJB3>{Described:** UNRESOLVED Demands 'jboss.ejb:service=EJBTimerService' **}
                


                • 5. Re: Testing Bootstrap Dependencies
                  istudens

                  I have completely rethought basic idea about the implementation of this test. Although I had consulted the issue with both Dominik and Jiri, I thought I was testing a nonsense. Maybe it will be better to reformulate the issue, because it is very brief.

                  I think the issue is about testing of bootstrap dependencies between services already in the profile. Therefore, for example the EJB3 test should contain a SAR using some EJB3 beans (stateless, stateful) with an appropriate dependency to Ejb3Container wrote in its jboss-service.xml.

                  The snippet of the EJB3's SAR code:

                  public class BootstrapDependencyEJB3Test
                   extends ServiceMBeanSupport
                   implements BootstrapDependencyEJB3TestMBean
                  {
                   ...
                  
                   @EJB
                   DummyStatelessLocal stateless;
                  
                   @Override
                   protected void startService() throws Exception
                   {
                   log.debug("BootstrapDependencyTest's SAR is starting");
                  
                   stateless.testCall(); // do nothing special
                  
                   log.debug("BootstrapDependencyTest's SAR is started");
                   }
                   ...
                  }


                  The SAR's jboss-service.xml:
                  <?xml version="1.0" encoding="UTF-8"?>
                  <deployment xmlns="urn:jboss:bean-deployer:2.0">
                  <bean name="BootstrapDependencyEJB3Test" class="org.jboss.test.deployers_jbas5349.sar.BootstrapDependencyEJB3Test">
                   <depends>Ejb3Deployer</depends>
                  </bean>
                  </deployment>


                  After start of the JBoss server the testcase tests just if the SAR was started.
                  Of course, the name of the SAR will be something like Aaa-bootstrap-dependency-jbas5349-ejb3.sar.

                  • 6. Re: Testing Bootstrap Dependencies
                    brian.stansberry

                    You shouldn't add the Ejb3Deployer
                    tag. The fact that the deployers are deployed before anything in deploy/ is one of the things being tested.

                    Have a look at the tests in the testsuite module org.jboss.test.deployers package, e.g. org.jboss.test.deployers.ear.test.EARDeploymentUnitTestCase. Those tests work by deploying something into a running AS and then using some utilities to remotely invoke on the MainDeployer and check the status of the deployments. Yours could do much the same thing, except you ensure the deployment is already there before the AS even starts.

                    Note that I *think* Adrian Brock wants the way those org.jboss.test.deployers unit tests work changed though. I don't recall the specifics; just recall a comment along those lines.

                    Also, as you confirm failures, please open separate JIRA issues for each; if its an EJB3 failure, in EJB3 project, otherwise in JBAS.

                    • 7. Re: Testing Bootstrap Dependencies
                      alesj

                       

                      "bstansberry@jboss.com" wrote:

                      Note that I *think* Adrian Brock wants the way those org.jboss.test.deployers unit tests work changed though. I don't recall the specifics; just recall a comment along those lines.

                      Adrian probably wanted them to be ported to ProfileService API,
                      due to using the right API - not using impl details.

                      And that's what I did:
                      - https://jira.jboss.org/jira/browse/JBAS-5823
                      But you need to use profileservice AS config to run them.

                      • 8. Re: Testing Bootstrap Dependencies

                         

                        "alesj" wrote:
                        "bstansberry@jboss.com" wrote:

                        Note that I *think* Adrian Brock wants the way those org.jboss.test.deployers unit tests work changed though. I don't recall the specifics; just recall a comment along those lines.

                        Adrian probably wanted them to be ported to ProfileService API,
                        due to using the right API - not using impl details.

                        And that's what I did:
                        - https://jira.jboss.org/jira/browse/JBAS-5823
                        But you need to use profileservice AS config to run them.


                        Correct, but the deployers tests just check you get the correct structure
                        from various edge case deployments.

                        • 9. Re: Testing Bootstrap Dependencies

                          The best way to write these tests would be use a test-config
                          that starts with the all configuation but without anything in deploy.

                          You then deploy an ear that includes everything,
                          * a war
                          * an ejb2
                          * an ejb3
                          * an mdb
                          * a rar
                          * a datasource
                          * an mbean
                          * a pojo

                          Then you deploy all the files from all/deploy and test the application works.

                          But then you repeat the test, by undeploying all/deploy and then redeploying
                          them in a different permutation.

                          Not only does this test that dependencies are working across all
                          our deployments, it also checks they can be stopped and restarted.
                          e.g. There is a known issue with EJB2 where this fails
                          https://jira.jboss.org/jira/browse/JBAS-5332

                          • 10. Re: Testing Bootstrap Dependencies
                            istudens

                             

                            "bstansberry@jboss.com" wrote:
                            You shouldn't add the <depends>Ejb3Deployer</depends>
                            tag. The fact that the deployers are deployed before anything in deploy/ is one of the things being tested.

                            Have a look at the tests in the testsuite module org.jboss.test.deployers package, e.g. org.jboss.test.deployers.ear.test.EARDeploymentUnitTestCase. Those tests work by deploying something into a running AS and then using some utilities to remotely invoke on the MainDeployer and check the status of the deployments. Yours could do much the same thing, except you ensure the deployment is already there before the AS even starts.

                            Note that I *think* Adrian Brock wants the way those org.jboss.test.deployers unit tests work changed though. I don't recall the specifics; just recall a comment along those lines.

                            Also, as you confirm failures, please open separate JIRA issues for each; if its an EJB3 failure, in EJB3 project, otherwise in JBAS.


                            When I remove the Ejb3Deployer tag the deployment of the SAR fails with
                            dependency on TransactionManager, see:
                            2008-09-23 09:50:10,733 DEBUG [org.jboss.ejb3.deployers.Ejb3Deployer] (main) ********* Ejb3Deployer Begin Unit: Aaabootstrapdependency-jbas5349-ejb3.sar jar:
                            Aaabootstrapdependency-jbas5349-ejb3.sar
                            2008-09-23 09:50:10,820 DEBUG [org.jboss.ejb3.interceptors.metadata.InterceptorMetaDataBridge] (main) ======> Creating interceptor metadata bridge
                            2008-09-23 09:50:11,088 DEBUG [org.jboss.ejb3.security.AuthenticationInterceptorFactory] (main) Creating interceptor with authentication manager 'null'
                            2008-09-23 09:50:11,100 DEBUG [org.jboss.tm.TransactionManagerLocator] (main) Unable to lookup: java:/TransactionManager
                            javax.naming.NameNotFoundException: TransactionManager not bound
                            


                            So there is a question if this is an expected result of the test or if the SAR should contain a 'depends' tag with 'jboss:service=TransactionManager'. I am not sure.

                            Of course I will refactor the test to use utilities from org.jboss.test.deployers.AbstractDeploymentTest to check the status of the deployment and run it inside profileservice AS config.

                            • 11. Re: Testing Bootstrap Dependencies
                              brian.stansberry

                              I'm probably missing something as I don't understand why Ejb3Deployer would prevent the transaction manager problem. Ejb3Deployer is in deployers/ and everything in deployers/ should be deployed before deployment of deploy/ even starts.

                              Looking at your log snippet, it looks like the deployment of the ejb3 jar is failing due to transaction manager not yet being deployed. Not sure, but from the preceding AuthenticationInterceptorFactory logging, I'm *guessing* its failing in creating a tx-related ejb interceptor. The exception stack trace should say. This is exactly the sort of thing this test should uncover. The transaction manager is deployed via a -jboss-beans.xml in deploy/, which will deploy after this sar unless a proper dependency has been programatically established by some deployer. So, don't hide the missing dependency by manually adding a dependency. :-)

                              • 12. Re: Testing Bootstrap Dependencies
                                istudens

                                 

                                "adrian@jboss.org" wrote:
                                The best way to write these tests would be use a test-config
                                that starts with the all configuation but without anything in deploy.

                                You then deploy an ear that includes everything,
                                * a war
                                * an ejb2
                                * an ejb3
                                * an mdb
                                * a rar
                                * a datasource
                                * an mbean
                                * a pojo

                                Then you deploy all the files from all/deploy and test the application works.

                                But then you repeat the test, by undeploying all/deploy and then redeploying
                                them in a different permutation.

                                Not only does this test that dependencies are working across all
                                our deployments, it also checks they can be stopped and restarted.
                                e.g. There is a known issue with EJB2 where this fails
                                https://jira.jboss.org/jira/browse/JBAS-5332


                                Ok, but if there will be none in the deploy dir, the ear will not be able to deploy successfully, because there will be no services such as jbossweb, transaction manager etc. as I mentioned earlier. Or will the AS wait for other deployments to finish the deployment of the ear? Even if that deployments will not be in the deploy dir in that time?


                                • 13. Re: Testing Bootstrap Dependencies
                                  istudens

                                   

                                  "bstansberry@jboss.com" wrote:
                                  I'm probably missing something as I don't understand why <depends>Ejb3Deployer</depends> would prevent the transaction manager problem. Ejb3Deployer is in deployers/ and everything in deployers/ should be deployed before deployment of deploy/ even starts.

                                  Looking at your log snippet, it looks like the deployment of the ejb3 jar is failing due to transaction manager not yet being deployed. Not sure, but from the preceding AuthenticationInterceptorFactory logging, I'm *guessing* its failing in creating a tx-related ejb interceptor. The exception stack trace should say. This is exactly the sort of thing this test should uncover. The transaction manager is deployed via a -jboss-beans.xml in deploy/, which will deploy after this sar unless a proper dependency has been programatically established by some deployer. So, don't hide the missing dependency by manually adding a dependency. :-)


                                  Thanks, I think so :)

                                  There is a bigger snippet of log:
                                  2008-09-23 09:50:10,733 DEBUG [org.jboss.ejb3.deployers.Ejb3Deployer] (main) ********* Ejb3Deployer Begin Unit: Aaabootstrapdependency-jbas5349-ejb3.sar jar: Aaabootstrapdependency-jbas5349-ejb3.sar
                                  2008-09-23 09:50:10,820 DEBUG [org.jboss.ejb3.interceptors.metadata.InterceptorMetaDataBridge] (main) ======> Creating interceptor metadata bridge
                                  2008-09-23 09:50:11,088 DEBUG [org.jboss.ejb3.security.AuthenticationInterceptorFactory] (main) Creating interceptor with authentication manager 'null'
                                  2008-09-23 09:50:11,100 DEBUG [org.jboss.tm.TransactionManagerLocator] (main) Unable to lookup: java:/TransactionManager
                                  javax.naming.NameNotFoundException: TransactionManager not bound
                                   at org.jnp.server.NamingServer.getBinding(NamingServer.java:564)
                                   at org.jnp.server.NamingServer.getBinding(NamingServer.java:572)
                                   at org.jnp.server.NamingServer.getObject(NamingServer.java:578)
                                   at org.jnp.server.NamingServer.lookup(NamingServer.java:317)
                                   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
                                   at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
                                   at javax.naming.InitialContext.lookup(InitialContext.java:351)
                                   at org.jboss.tm.TransactionManagerLocator.tryJNDI(TransactionManagerLocator.java:120)
                                   at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:101)
                                   at org.jboss.aspects.tx.TxPropagationInterceptor.<init>(TxPropagationInterceptor.java:48)
                                   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
                                   at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
                                   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
                                   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
                                   at java.lang.Class.newInstance0(Class.java:350)
                                   at java.lang.Class.newInstance(Class.java:303)
                                   at org.jboss.aop.advice.GenericAspectFactory.createPerVM(GenericAspectFactory.java:145)
                                   at org.jboss.aop.AspectManager.createPerVmAspect(AspectManager.java:1942)
                                   at org.jboss.aop.AspectManager.getPerVMAspect(AspectManager.java:1918)
                                   at org.jboss.aop.Domain.getPerVMAspect(Domain.java:788)
                                   at org.jboss.aop.Domain.getPerVMAspect(Domain.java:788)
                                   at org.jboss.aop.Domain.getPerVMAspect(Domain.java:773)
                                   at org.jboss.aop.advice.ScopedInterceptorFactory.create(ScopedInterceptorFactory.java:69)
                                   at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:1318)
                                   at org.jboss.ejb3.interceptors.container.ManagedObjectAdvisor.createInterceptorChain(ManagedObjectAdvisor.java:141)
                                   at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:1929)
                                   at org.jboss.aop.MethodMatchInfo.applyBinding(MethodMatchInfo.java:152)
                                   at org.jboss.aop.MethodMatchInfo.overridePopulateBindings(MethodMatchInfo.java:143)
                                   at org.jboss.aop.MethodMatchInfo.populateBindings(MethodMatchInfo.java:92)
                                   at org.jboss.aop.Advisor.finalizeMethodChain(Advisor.java:1540)
                                   at org.jboss.aop.ClassAdvisor.finalizeChains(ClassAdvisor.java:747)
                                   at org.jboss.aop.ClassAdvisor.createInterceptorChains(ClassAdvisor.java:607)
                                   at org.jboss.aop.ClassAdvisor$1.run(ClassAdvisor.java:304)
                                   at java.security.AccessController.doPrivileged(Native Method)
                                   at org.jboss.aop.ClassAdvisor.attachClass(ClassAdvisor.java:274)
                                   at org.jboss.ejb3.interceptors.container.ManagedObjectAdvisor.initialize(ManagedObjectAdvisor.java:174)
                                   at org.jboss.ejb3.aop.ExtendedManagedObjectAdvisor.initialize(ExtendedManagedObjectAdvisor.java:70)
                                   at org.jboss.ejb3.interceptors.container.AbstractContainer.initializeAdvisor(AbstractContainer.java:162)
                                   at org.jboss.ejb3.aop.BeanContainer.initialize(BeanContainer.java:204)
                                   at org.jboss.ejb3.EJBContainer.<init>(EJBContainer.java:240)
                                   at org.jboss.ejb3.session.SessionContainer.<init>(SessionContainer.java:116)
                                   at org.jboss.ejb3.session.SessionSpecContainer.<init>(SessionSpecContainer.java:91)
                                   at org.jboss.ejb3.stateless.StatelessContainer.<init>(StatelessContainer.java:106)
                                   at org.jboss.ejb3.Ejb3AnnotationHandler.getStatelessContainer(Ejb3AnnotationHandler.java:310)
                                   at org.jboss.ejb3.Ejb3AnnotationHandler.getContainers(Ejb3AnnotationHandler.java:203)
                                   at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:698)
                                   at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:658)
                                   at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:640)
                                   at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:603)
                                   at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:512)
                                   at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:195)
                                   at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:108)
                                   at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45)
                                   at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
                                   at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169)
                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1285)
                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1003)
                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:944)
                                   at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                                   at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
                                   at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                                   at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
                                   at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                                   at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
                                   at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                                   at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:627)
                                   at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
                                   at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:265)
                                   at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:143)
                                   at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
                                   at org.jboss.Main.boot(Main.java:209)
                                   at org.jboss.Main$1.run(Main.java:544)
                                   at java.lang.Thread.run(Thread.java:595)
                                  


                                  • 14. Re: Testing Bootstrap Dependencies

                                     

                                    "istudens@redhat.com" wrote:

                                    Ok, but if there will be none in the deploy dir, the ear will not be able to deploy successfully, because there will be no services such as jbossweb, transaction manager etc. as I mentioned earlier. Or will the AS wait for other deployments to finish the deployment of the ear? Even if that deployments will not be in the deploy dir in that time?


                                    Yes, that's what you are testing. If the ear is deployed first, then the ejb service, tomcat,
                                    transaction manager, etc. are deployed after,
                                    the ear should still work once everything is deployed
                                    (i.e. regardless of the order of deployment)

                                    The idea of the test is spot where this is not the case so we can fix the dependency.

                                    1 2 Previous Next