I know this old, but I have a similar error with Tomcat, and I agree with @johnnyjava & @pratiksha11, the so called resolution with the property map_accuracy_errors_ci_types_to_exclude is actually not resolving but hiding an issue.
My understanding is that this is saying is that while there is a containment rule defined for Tomcat (in the Metadata Editor), the Top-down discovery did not create the expected inclusion connection (with a tomcat WAR).
Here's my analysis for my case with tomcat, I guess it might fail with other patterns for similar reason :
When looking at the Tomcat pattern, I see we have 2 identification sections and 1 connection section. The connection section is the part responsible for creating that inclusion connection (with a tomcat WAR). And here it's failing because it relies an "apps" variable which is empty.
That "apps" variable is supposed to be set by the identification sections. When looking at the discovery logs, first I saw the first section (http and AJP identification) failed and the second one succeeded. That 2nd section is visibly a fallback, a downgraded option that will still retrieve some information about the tomcat process but not everything and thus it does not set the apps variable. Basically it seems to only extracts information from the command line and does not parse configuration files.
So to actually get the full pattern to work without the error, the 1st section would need to be working, but it relies on a Find process strategy defined as "Listening port" and fails from the beginning.
Then I don't what changed but the 1st section finally got executed the next day. It then failed with the same result in the end, but here the reason was clear from the discovery logs : permission denied on the tomcat web.xml file.
In conclusion this error is actually just a consequence of another error that you need to find in the discovery logs. And as often this can be a credential/permission issue.
