Multiple matching files by name in parsing deployer

[alesj]

While doing webbeans mocking, I came up with the following issue.

As current WarStructure adds all of WEB-INF/lib jars's META-INF
as meta data location:

 archives = webinfLib.getChildren(webInfLibFilter);
 // Add the jars' META-INF for metadata
 for (VirtualFile jar : archives)
 {
 // either same as plain lib filter, null or accepts the jar
 if (webInfLibMetaDataFilter == null || webInfLibMetaDataFilter == webInfLibFilter || webInfLibMetaDataFilter.accepts(jar))
 metaDataLocations.add("WEB-INF/lib/" + jar.getName() + "/META-INF");
 }

one could silently end up with wrong metadata.

e.g. JPA PersistenceParsingDeployer::setName("persistence.xml")
and then some lib jar accidentally has some persistence.xml leftover in its META-INF.
There is a chance this is gonna be picked up,
since we return on first found/matching file:

 protected VirtualFile searchMetaDataLocations(String name)
 {
 VirtualFile result = null;
 for(VirtualFile location : getMetaDataLocations())
 {
 try
 {
 result = location.getChild(name);
 if (result != null)
 {
 if (log.isTraceEnabled())
 log.trace("Found " + name + " in " + location.getName());
 deployed();
 break;
 }
 }
 catch (IOException e)
 {
 log.debug("Search exception invocation for metafile " + name + " in " + location.getName() + ", reason: " + e);
 }
 }
 return result;
 }

What would be a proper way to handle this?
This is current behavior when you call VFSDeploymentUnit::getMetaDataFile(String name).

[starksm64]

Without a jboss-structure.xml excluding a jar from the meta-inf bucket, you can't. We can't both treat WEB-INF/lib as a source for deployment descriptors and know when not to do so without some user input.

[alesj]

Without a jboss-structure.xml excluding a jar from the meta-inf bucket, you can't. We can't both treat WEB-INF/lib as a source for deployment descriptors and know when not to do so without some user input.

I was thinking more about it yesterday
and you're absolutely right.

What eventually triggered my check, was when I was getting unexpected web-beans.xml -- > WBMD.
But it was only unexpected since I missed some detail. :-)