-
30. Re: Ordering of .ear subdeployments
vickyk Aug 24, 2006 2:10 AM (in response to dimitris)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 Aug 24, 2006 3:48 AM (in response to 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 Aug 25, 2006 4:20 AM (in response to 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).
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 Aug 25, 2006 7:35 AM (in response to 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 Aug 25, 2006 10:34 AM (in response to dimitris)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 Aug 26, 2006 9:02 AM (in response to dimitris)
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 Aug 26, 2006 3:25 PM (in response to dimitris)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 Aug 26, 2006 4:00 PM (in response to dimitris)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 Aug 27, 2006 11:55 PM (in response to dimitris)
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 Aug 28, 2006 11:06 AM (in response to dimitris)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 Apr 9, 2007 2:30 PM (in response to dimitris)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 Jul 11, 2007 1:05 PM (in response to dimitris)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 Jul 11, 2007 1:39 PM (in response to dimitris)What are the contents of your jboss-app.xml file ?
-
43. Re: Ordering of .ear subdeployments
sailuravi Jul 11, 2007 4:19 PM (in response to dimitris)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.