https://bz.apache.org/bugzilla/show_bug.cgi?id=59226
--- Comment #6 from Ignacio del Valle Alles <idelv...@brutusin.org> --- (In reply to Mark Thomas from comment #4) > (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. My reasoning was based on the wrong assumption that these entries were only read by the System class loader and only when executed as "java -jar" (don't ask me why). So yes, the solution is simpler and can be implemented just by scanning the manifest. I'll work on it and send a new PR -- 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
