|Summary:||If JAR scan experiences a stack overflow, give the URL from which each class in the loop was loaded in the complaint|
|Product:||Tomcat 7||Reporter:||Edward Kuns <eddie.kuns>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||Proposed patch that implements the feature enhancement|
Description Edward Kuns 2014-12-18 18:39:27 UTC
Created attachment 32304 [details] Proposed patch that implements the feature enhancement When you get a class loop that causes a stack overflow exception in JAR scanning, the class names are currently listed, but not the location from which each class was loaded. If a class is unexpectedly found in more than one location (which will often be the source of this problem), then one has to search every possible JAR to figure out the root cause. It would really help understand these problems if the location from which each class was loaded was included in the error report. I will attach a proposed patch that adds this.
Comment 1 Edward Kuns 2014-12-18 18:45:25 UTC
The provided patch adds three pieces of information to the current error report: 1) It adds the URL from which each class was loaded, and 2) If the problem is a class loop, e.g., A.class extends B.class which extends A.class, then the error report will now explicitly say it's a loop. 3) If the full list of classes is not provided, then "->..." is added to make it clear that the full list is too long and is not provided. We ran into this when a JAR was in an unexpected place (and an old version of that JAR to boot). Just knowing the classes involved isn't enough!