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

        Sounds definitely better that the <unifield-loader> approach , looks simpler to implement !!!


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

        I did not understand this, why would the user define the same module in both the descriptors. Can you give some use case?
        I will do the impact analysis for this approach and will come up with the additional changes we need to do.


        • 31. Re: Ordering of .ear subdeployments
          dimitris

          The code changes for this approach are minimal. What you've done already, plus an attribute in the ear metadata (defaulting to 'strict') to control whether to set the DeploymentInfo flag or not, (plus fixing the failing test by adding the 'implicit' flag).

          My only concern is the case where you need to declare the modules in the jboss-app.xml descriptor to get total order (e.g. a -ds.xml and an ejb jar).

          I don't know whether the standard would require the ejb module to appear in the application.xml descriptor, too.

          • 32. Re: Ordering of .ear subdeployments
            vickyk

             


            The code changes for this approach are minimal. What you've done already, plus an attribute in the ear metadata (defaulting to 'strict') to control whether to set the DeploymentInfo flag or not, (plus fixing the failing test by adding the 'implicit' flag).

            This works fine , I have tested it on my local system ....


            -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 ;) )

            I am not sure if bstansberry would vote for changing the deployment descriptors .i.e modifying the test cases.
            The approach looks ok to me now



            • 33. Re: Ordering of .ear subdeployments
              dimitris

              The important bit is to have a solution that is backwards compatible.

              Regarding the default, my preference would be the behaviour closest to the j2ee standard (strict order), but if there are too many users depending on the implicit order, let keep them happy.

              Vicky, can you be over with this today?

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

                Please don't interpret the following as a vote (at least not in the Apache sense of "intent to veto"). My -1 before was for changing the test w/o hashing through the issues; you've now hashed through the issues :)

                I do think having apps that work in 4.0.4 no longer work in 4.0.5 is not too good, particularly since we've been teaching the implicit ordering rules in training classes for a long time.

                I don't have anywhere near the same level of concern about an app working in 4.0.4 not working without tweaking in 5.0.0, so one option is to change the default to strict for 5.0.0 and leave it at implicit for 4.x.

                If you guys go with strict for 4.0.5, I certainly don't mind having the testbeancluster.jar changed to conform.

                • 35. Re: Ordering of .ear subdeployments
                  vickyk

                   


                  Vicky, can you be over with this today?

                  Done !!!!
                  It is already at the SVN branch 4 .


                  but if there are too many users depending on the implicit order, let keep them happy.

                  I have kept the default as implicit , so no need to change the test case for the clustering in Jboss4.x version .
                  We will make the default as strict for the Jboss5 release so will have to change the test case for clustering there ...


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

                    I think with the latest change if an ear doesn't have a jboss-app.xml, deployment will fail with an NPE at EARDeployer line 275. This is causing o.j.t.cluster.test.CrossContextCallsTestCase to fail.

                    I'd have just fixed this by changing 'if (moduleOrder.equals("strict"))' to 'if ("strict".equals(moduleOrder))' but I saw that in the else block it's logging a warning. My recommendation would be to get rid of the warning (or log it at a lower level) and use the "strict".equals(...) syntax. With this WARN log, anyone who upgrades to 4.0.5 and doesn't add this new config element will get a WARN log. A WARN in a production app is a serious problem; to make it go away the users will have to add the new element. If they are going to have to add the element there is no point having a default.

                    Actually, "strict".equalsIgnoreCase(moduleOrder) would be better.

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

                      Vicky, to eliminate spurious testsuite failures I've fixed EARDeployer to prevent any NPE. I'll leave it to you to decide what to do about the logging.

                      • 38. Re: Ordering of .ear subdeployments
                        vickyk

                         


                        I think with the latest change if an ear doesn't have a jboss-app.xml, deployment will fail with an NPE at EARDeployer line 275.

                        I dont think so as J2eeApplicationMetaData is taking care of this .

                        //Get the Deployment Ordering style
                         Element moduleOrderElement = getOptionalChild(rootElement, "module-order");
                         if (moduleOrderElement != null)
                         {
                         moduleOrder = getElementContent(moduleOrderElement);
                         }
                         else
                         {
                         moduleOrder = "implicit";
                         }
                        



                        With this WARN log, anyone who upgrades to 4.0.5 and doesn't add this new config element will get a WARN log. A WARN in a production app is a serious problem; to make it go away the users will have to add the new element.

                        The warn will appear only if the user is not using the module order as strict or implicit , say the user has typed errstrict in the module-order ie
                        <module-order>errstrict</module-order>
                        

                        The value of implicit will be taken , there will be no failure but the warning will be displayed .


                        This is causing o.j.t.cluster.test.CrossContextCallsTestCase to fail.

                        I am not sure why this fails can you give me some more details on this ?




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

                          OK, the problem then is in J2eeApplicationMetaData. Method importJBossAppXml is where moduleOrder gets set to a non-null value. If the ear doesn't have a jboss-app.xml file, that method doesn't get called and moduleOrder gets left at null. That caused the NPE I described in line 275 of EARDeployer.

                          If you initialize moduleOrder at the default value instead of null, this problem will go away. Then your WARN log will function as you intend -- to complain only if they set the value to something incorrect.

                          BTW, I didn't port the fix I did for the NPE to HEAD, just did it in 4.0.

                          • 40. Re: Ordering of .ear subdeployments
                            pakemann

                            Does this ordering govern un-deployment as well?

                            I have an ear file consisting of multiple EJB3.0 modules and one web module. This system needs to perform certain operations at startup and shutdown which rely on all the EJB3.0 modules being available.

                            Presently I am using module-order to deploy the web-module last, then using a servlet init() method to run the startup sequence.

                            I would like to do the reverse for shutdown with destroy(), but I need to know that the modules will undeploy in the reverse order that they were deployed.

                            Note: I am also looking at replacing the init()/destroy() with ServletConetxtListener contextInitialized/contextDestroyed

                            Thanks,
                            -Peter

                            • 41. Re: Ordering of .ear subdeployments
                              sailuravi

                              Currently Using 4.0.5 GA version and couldn't get the ordering in the application.xml to work.. It looks like it's loading the modules in an alphabetical order rather than in the order given in the application.xml.

                              • 42. Re: Ordering of .ear subdeployments
                                vickyk

                                What are the contents of your jboss-app.xml file ?

                                • 43. Re: Ordering of .ear subdeployments
                                  sailuravi

                                  After having module order to strict .. the modules are loading as specified in application.xml... Earlier I didn't have jboss-app.xml at all and thought that the default is in the order given in appliacation.xml but the default is implicit...

                                  <module-order>strict</module-order> did it. Thanks.

                                  1 2 3 Previous Next