When deploying an EAR into WebSphere, what's the cause of a "duplicate entry" SaveFailureException?

When attempting to install the EAR, the following exception results:

Caught Exception installing App开发者_如何学ClicationName  
com.ibm.ws.scripting.ScriptingException: com.ibm.websphere.management.application.client.AppDeploymentException: AppDeploymentException: []  
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.SaveFailureException: META-INF/application.xml  
META-INF/application.xml  
duplicate entry: META-INF/application.xml  
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.SaveFailureException: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.SaveFailureException: META-INF/application.xml  

Needless to say, the EAR file does not have two application.xml files within it, so I can't explain the "duplicate entry" error. Is this exception familiar to anyone? How is it resolved?

---

My advice is to open/explore the ear with 7-zip and make sure there are not two application.xml files at the META-INF level. Zip will create duplicate entries for files under many conditions, particularly if you are zipping source files together from multiple directories. We just had this exact same problem.

---

I faced this today..

Ear.setAppXml(): ear task in ant, are putting the duplicate entry of META-INF/application.xml, while re-packing an EAR (from the same location where its exploded).

setAppXml(): appxml attribute in ear task, needed a path to the application.xml file. If the path is specified as {exploded.dir}/META-INF/application.xml, then it puts two entries.

Solution:

Copy the META-INF/application.xml to some /tmp/app.xml
Pass "/tmp/app.xml" for setAppXml() / "appxml" in ear task
Delete the entry: {exploded.dir}/META-INF/application.xml
Pack the EAR now.

hope this helps..

---

Check if there is another application with the same name already deployed onto that server.

---

Another option is that you have another JAR file, located inside the EAR's root, that has a META-INF/application.xml in it.

Sounds bizarre? I know, but I've seen this happen before (developers included EAR files within EAR files).

---

I had this issue and it turned out to be a space issue on the server from which I was performing the deploy. The target had plenty of space, the server that was doing the deploy was completely out.