To be blunt, what I do is I create a new domain, copy over any libraries and such that I have (JDBC jars typically), and then I run WinMerge on the domain.xml file from the old to the new, and manually move over my changes.
It's remarkably efficient and straight forward, frankly.
Kind of annoying that I have to do that, but I've found over time that as they add different facilities and tweak them in the appserver, if you copy over your old domain.xml, then that may well stomp on some of those new features (this is more of an issue as you're trying to keep up with the latest builds).
I find it easiest if I undeploy my applications first from the original version, leaving just the resource configurations and such in the configuration. Then I simply deploy the apps in to the new server. I do that to limit how much stuff there is in the domain.xml, and redeploying the apps is generally straight forward, so undeploying them is cheap enough that I don't worry about it (for my apps, your apps may be different).
It DOES sound horrible, but WinMerge is such a good tool, it's really simple and efficient (it's trivial to copy over blocks from one side to the other). I just followed the philosophy of "copying over the stuff I recognize" and leave the rest. Things like connection pools, virtual servers, JMS resources, etc. If I don't recognize it in the old one, and it's different from the new, I simply don't copy that change over. Odds are, for example, you can bring things over wholesale.
The domain.xml is organized and formatted well enough to make this work.
Also, make sure you start your new domain (some entries get created when the server starts up) before you do your merge.
WinMerge is free and available on line, but it's only for Windows. No doubt you can use any visual DIFF merging tool.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=231000