https://bz.apache.org/bugzilla/show_bug.cgi?id=59226
--- Comment #4 from Mark Thomas <ma...@apache.org> --- (In reply to Ignacio del Valle Alles from comment #3) > Hi Mark, this problem comes for system (application) class loader, that is > responsible of handling class-path entries, not returning manifest jar urls > when executed as java -jar. No, the problem is wider than that. See the second of my notes in comment #2 above. > If there is a portable way of knowing the executable jar at runtime, the > solution would be trivial: just parse its manifest class path entries. But > there is not (AFAIK). Not relevant. See above. > The suggested change does not get jar entries from the class-path header of > the manifest, instead it infers jar entries from the enumeration of manifest > that it sees (and its parent don't). > > It is true that it requires jars referenced in the manifest of the > executable jar to have a manifest in order to be scanned, but this improves > the current behavior of not scanning them at all It is arguable whether a flawed solution is better than no solution. My preference is to fix it properly. > For code simplicity I added the same processing for every class loader in > Tomcat, but it is true, that I adds a little overhead, so I have just > created a new pull request that applies the hack only to the system class > loader. Limiting the scan to the system class loader is as flawed as including the web application class loader. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
