1 2 3 Previous Next 43 Replies Latest reply on Jul 11, 2007 4:19 PM by sailuravi Go to original post
      • 15. Re: Ordering of .ear subdeployments
        dimitris

        No, no, we need a test! In fact, you should have the test before even you make the fix (to know the fix is working).

        You don't need to modify the code, just look for a smarter solution.

        E.g. I have the feeling if you do a listDeployed() on the MainDeployer you get back the list of deployments in the order they are actually deployed. So iterate those and see if you get what you'd expect.

        • 16. Re: Ordering of .ear subdeployments
          vickyk

           


          E.g. I have the feeling if you do a listDeployed() on the MainDeployer you get back the list of deployments in the order they are actually deployed. So iterate those and see if you get what you'd expect.


          After looking at the code I could see the following code sippet in the init of the MainDeployer
          if (!inLocalCopyDir(deployment.url) && deploymentList.contains(deployment) == false)
           {
           deploymentList.add(deployment);
           log.debug("Watching new file: " + deployment.url);
           }
          

          The deploymentList contains the entries which will be rendered by the listDeployed() , this does not give the proper information if the deployments are packaged.

          So the alternative to get the actual deployment ordering would be based on the lastDeployed field of the DeploymentInfo . This seems to be working appropriately .
          The only concern in this case is that the precision is lost as the the lastDeployed field could be same for some of the sub-deployments. Actually this is because the System.currentTimeMillis() is not enough for this purpose .
          We can either think of using the System.nanoTime() in the MainDeployer but by doing this we will loose the backward compartability , as this method has been a part of the jdk1.5 .
          What i did to make the UnitTest give me the accurate results was to include the following code snippet
           deployment.lastModified=lastModified;
           //Introduced for Testing JBAS-2904
           try{
           Thread.sleep(1);
           }
           catch(InterruptedException ex){
           }
           //introduced for Testing JBAS-2904
           deployment.lastDeployed=System.currentTimeMillis();
          


          This gives the proper lastDeployed precision .
          Since this code won't be called so frequently , thus will not result in the performance hit . This gives the appropriate deployment ordering .

          Are there any other ways we can get the actual Deployment Ordering ?

          Regards
          Vicky

          • 17. Re: Ordering of .ear subdeployments
            vickyk

             

            deployment.lastModified=lastModified;
             //Introduced for Testing JBAS-2904
             try{
             Thread.sleep(1);
             }
             catch(InterruptedException ex){
             }
             //introduced for Testing JBAS-2904
             deployment.lastDeployed=System.currentTimeMillis();
            

            This is included for the lastDeployed timing precision and will be useful for the cases which need to list the actual deployment ordering for a particular deployment.


            • 18. Re: Ordering of .ear subdeployments
              dimitris

              Again, stop thinking of changes of this type, like adding sleep() in the production code!

              Instead, add a .sar to your ear that instantiates an mbean that introduces a small delay in its startService() method, to get your delay. Then make the .sar to be the last module in application.xml (by default it should be deployed first, I guess, so the test should fail), then compare the dates and expect this to be the last deployment.

              • 19. Re: Ordering of .ear subdeployments
                vickyk

                 


                Instead, add a .sar to your ear that instantiates an mbean that introduces a small delay in its startService() method, to get your delay. Then make the .sar to be the last module in application.xml (by default it should be deployed first, I guess, so the test should fail), then compare the dates and expect this to be the last deployment.

                Oops if I understood this clearly what you are trying to say is that the entire testing should be concluded based on the result that the SAR should be deployed last .
                It makes a sense to me , but I was thinking of a way to get the a proper ordering as i could get by introcuing some delay or by System.nanoTime() usage .
                Anyway I think I will continue with this .
                Well I dont think I need to create a seperate EAR , I will use the \unpacked-ear2.ear from the testsuite which I have been doing during executing the test suites till now .



                • 20. Re: Ordering of .ear subdeployments
                  vickyk

                  We have not discussed the setting options of the Comparator in the EARDeployer , if we are setting this from the configuration file ie ear-deployer.xml file then we might need to have a test cases for this too.
                  Should we include the testcase for this now?

                  I can not think of the use case where the user will use the explicit comparator and not rely on the settings done in the application.xml file.
                  My personal view would be not to give this feature to user by default , if we notice the user asking for it we will include this at that stage .
                  Would it be ok not to have this as of now?

                  • 21. Re: Ordering of .ear subdeployments
                    vickyk

                     


                    Instead, add a .sar to your ear that instantiates an mbean that introduces a small delay in its startService() method, to get your delay

                    The startService() will be invoked after the init() is over , how will this be useful .
                    I think I have not understood what you are trying to convey .

                    • 22. Re: Ordering of .ear subdeployments
                      dimitris

                      Vicky, if I need to look at this in every possible detail, I may very well solve it myself, no?

                      Make an .ear containing just 2 .sars, A.sar, B.sar. Each sar has same mbean deployed under a different name, with a start() method introducing a small delay and an attribute to record he start time of the mbean. Use an application.xml with the B.sar listed first, and query the 2 mbeans to find out the actual deployment order.

                      For now, we don't need to expose the Comparator in the EARDeployer.

                      • 23. Re: Ordering of .ear subdeployments
                        vickyk

                         


                        Vicky, if I need to look at this in every possible detail, I may very well solve it myself, no?

                        Right , point is noted .
                        I am done with the changes and will commit the changes in the jboss-head, currently I am not able to checkin the files. Let me get this first sorted , btw here are the final list of changes
                        1) DeploymentInfo
                        2) MainDeployer
                        3) Changes in the deployer.xml present at here
                        jboss-head\testsuite\imports\sections
                        4) Added jbas2904 folder to the jboss-head\testsuite\src\main\org\jboss\test\deployers\jbas2904 , this contains the 2 MBeans (A and B as we have been discussing) .
                        5) Added jbas2904 folder to the jboss-head\testsuite\src\resources\deployers\jbas2904, this contain the dd related files.....


                        • 24. Re: Ordering of .ear subdeployments
                          brian.stansberry

                          This change has broken the use case where a datasource is packaged in an ear with an ejb jar that use the datasource.

                          See http://jira.jboss.com/jira/browse/JBAS-3503 for the problem. The testcase deploys test-cif.ear. The ear includes an ejb jar and a -ds.xml file for the datasource. The ejbs fail to deploy due to the inability to find java:/CIFTestDS in JNDI.

                          Looking at the log, service jboss.jca:service=DataSourceBinding,name=CIFTestDS and the other
                          datasource related services are started *after* the ejbs, which explains
                          the failure.

                          My *guess* as to what is going on is the services are ordered based on their ordering within the deployment descriptors. A side affect is those listed in application.xml come before those listed in jboss-app.xml. The ds can only be listed in jboss-app.xml, so it comes later. The JBAS-2904 work removed the subsequent comparator-based sorting that would have put the ds before the ejb jar.

                          • 25. Re: Ordering of .ear subdeployments
                            vickyk

                             


                            A side affect is those listed in application.xml come before those listed in jboss-app.xml.

                            Well that is correct . Actually the ear deployer reads the application.xml first and then the jboss-app.xml file . So as per the JBAS-2904 the ordering seems to be correct .
                            I can think of the possible way to get the JBAS-3503 rectified
                            1) Modify the Test suite , removal of the -ds.xml from the jboss-app.xml and deploy this prior deploying the ejb .
                            2) Modify the EARDeployer to read the jboss-app.xml first and then the application.xml. This needs to be done in the init(..) of the EARDeployer . Personally I dont favor this and does not fit .

                            • 26. Re: Ordering of .ear subdeployments
                              brian.stansberry

                               

                              "vickyk" wrote:

                              I can think of the possible way to get the JBAS-3503 rectified
                              1) Modify the Test suite , removal of the -ds.xml from the jboss-app.xml and deploy this prior deploying the ejb .


                              -1. The testcase ear is a perfectly valid deployment, and I doubt it's unusual in the real world. I know at my previous employer we had several ears like this. (I didn't write the testcase ear, so I'm not responsible for both examples ;) )

                              2) Modify the EARDeployer to read the jboss-app.xml first and then the application.xml. This needs to be done in the init(..) of the EARDeployer . Personally I dont favor this and does not fit .


                              I agree, doing that doesn't have a good "feel." That's because it doesn't address the fundamental problem -- JBAS-2904 assumes there is a clear ordering expressed in the ear deployment descriptors. But, there isn't, because there are two descriptors with mutually exclusive content. IMHO a correct solution to JBAS-2904 requires a clear way for the user to define the complete ordering.

                              This isn't my call, but JBAS-2904 doesn't feel like something that should go out in a point release.

                              • 27. Re: Ordering of .ear subdeployments
                                starksm64

                                The ordering solution needs to be complete, so the jboss-appl.xml needs to have an explicit ordering section that allows a unified ordering of both the application.xml and jboss-app.xml deployments.

                                In the point release we should also be able to disable the change in ordering behavior to avoid breaking existing deployments like the test-cif.ear.

                                • 28. Re: Ordering of .ear subdeployments
                                  vickyk

                                   


                                  The ordering solution needs to be complete, so the jboss-appl.xml needs to have an explicit ordering section that allows a unified ordering of both the application.xml and jboss-app.xml deployments.

                                  So we need to have the additional section in the jboss-app.xml file where in we will define the unified ordering. Additionally the EARDeployer needs to prepare the J2eeApplicationMetaData associated with the DeploymentInfo from this unified listing in the jboss-app.xml . What we need is
                                  1) To have <unified-order> tag in the jboss-aap.xml file , this will list the deployments in order .
                                  2) The EARDeployer should be able to prepare the J2eeApplicationMetaData from the <unified-order> when it is present in the jboss-app.xml file .
                                  3) Based on the presence of <unified-order> the DeploymentInfo.sortedSubDeployments flag should be made true . This will be doing the job of the comparator what we were planning .
                                  Scott , is this what you had been expecting ?


                                  In the point release we should also be able to disable the change in ordering behavior to avoid breaking existing deployments like the test-cif.ear.

                                  Ok I will undo the changes in Branch_4_0 (SVN) , we can put it back once the complete ordering is incorporated .

                                  Vicky

                                  • 29. Re: Ordering of .ear subdeployments
                                    dimitris

                                    Maybe a simpler/better solution is to add in jboss-app.xml a new tag:

                                    <module-order>implicit|strict</module-order>

                                    with 'implicit' being the legacy behaviour, and 'strict' work by simply putting the the application.xml & jboss-app.xml modules in that order.

                                    If modules from the 2 descriptors need to be arbitrarily mixed (e.g. a -ds.xml before an ejb jar), they can always be moved to jboss-app.xml (we already support this).

                                    The only restriction is a module must appear only once in the 2 descriptors.

                                    This is essentially the same with adding a new list (like unified-order) but we reuse the existing one, and add the extra flag to specify what we want.

                                    On the other hand, I would argue that 'strict' should be the default, which is the "correct" behaviour, especially in the absence of a jboss-app.xml descriptor. If an old deployment gets broken, they can simply add the 'implicit' flag.