On JB3.0.0beta2/Tomcat4.0.2 (Feb22) deploying an ear with a v2.3 war would generate a parser error regarding a malformed external DTD entity. The embedded war would still work but when updating to a new ear would fail more seriously (the container would incorrectly remember the context so it wouldn't allow the new version to overlap it). BTW, this isn't a Tomcat specific problem, Jetty would report the same exception and then additionally gobble all system memory (details are unclear).
The problem would remain even if I exchanged crimson for xerces. (so, I stuck with crimson since it's default.)
After a lot of grief, I introduced a small modification to XmlFileLoader.java to register locally a copy of web-app_2_3.dtd. I made the actual file available by copying it to server/src/resources/org/jboss/metadata.
The result is that I currently have built a JBoss(Head)/Tomcat4.0.3 bundle where I can deploy, undeploy and redeploy ears with wars in them without trouble. (I still have to undeploy and wait a couple seconds before redeploying, but it works.)
My question is: why did I have to do this ugly thing? JBoss2.4.4/Tomcat4 worked with ears having v2.3 wars in them. JBoss2.4.4's XmlFileLoader did not register web-app_2_3.dtd nor did it have a copy of it (see metadata.jar), but it worked!
I wonder if this is a solution, an incorrect solution or an ugly workaround.
Opinions?
