Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: class loading problem with fat jars (#7786)#7787

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
Thomas-Bergmann wants to merge1 commit intodependency-check:main
base:main
Choose a base branch
Loading
fromintershop:bugfix/7786-fat-jar

Conversation

Thomas-Bergmann
Copy link

Description of Change

Instead of using URL.openStream(), we propose to use the class or classloader getResourceAsStream to load resources from class path.

Related issues

Have test cases been added to cover the new functionality?

no - if you have any idea how to test a fat jar problem, I would be happy

@boring-cyborgboring-cyborgbot added corechanges to core utilschanges to utils labelsJul 4, 2025
@aikebah
Copy link
Collaborator

@Thomas-Bergmann Your current fix does not carry the core rationale behind the current loading code: to ensure that we only silently load (in addition to user-configured suppressions) project-vetted false positive suppressions that we made part of the codebase (or in rare cases: the similar named file that someone re-packaged together with our classes in one and the same jar-file).

Simply using the classloader (which we did in past) will load a resource from whichever jar-file is the first to contain a dependencycheck-base-suppression.xml resource. At the very least a similar guard as in the original proposed resourceloading in#7544 would be required to validate that we load the resources from the same jar that our own code originates from.

Based on your reported error I believe that original code that was simplified to direct the URL-based loading does not cover the case of your jar, which I wouldn't term as a fat-jar, but as a jar-with-jars. A fat-jar I consider a jar in which the contents of several original jars are merged together, which would perfectly survive the current code as those would use the regular file:-URL scheme. The problematic part in your scenario is thenested: URI scheme that your jar-with-jars capable classloader uses.

jeremylong reacted with thumbs up emoji

@aikebah
Copy link
Collaborator

aikebah commentedJul 12, 2025
edited
Loading

@Thomas-Bergmann looking at Spring's documentation of its nested classloading [1] and the reported error message I expect that it would only be needed to special-case anested:-prefix detection inside the.jar suffix branch to compose ajar:nested: URL instead of ajar:file: URL from the CodeSource. Would you be willing to test and validate that it indeed makes things work in your setup and adapt your PR accordingly when successful?

As in: the delta would be reduced to only:

diff --git a/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java b/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.javaindex e5b928417..54d2b699e 100644--- a/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java+++ b/core/src/main/java/org/owasp/dependencycheck/analyzer/AbstractSuppressionAnalyzer.java@@ -199,7 +199,11 @@ public abstract class AbstractSuppressionAnalyzer extends AbstractAnalyzer {         final URL jarLocation = AbstractSuppressionAnalyzer.class.getProtectionDomain().getCodeSource().getLocation();         String suppressionFileLocation = jarLocation.getFile();         if (suppressionFileLocation.endsWith(".jar")) {-            suppressionFileLocation = "jar:file:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;+            if (suppressionFileLocation.startsWith("nested:")) {+                suppressionFileLocation = "jar:nested:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;+            } else {+                suppressionFileLocation = "jar:file:" + suppressionFileLocation + "!/" + BASE_SUPPRESSION_FILE;+            }         } else {             suppressionFileLocation = "file:" + suppressionFileLocation + BASE_SUPPRESSION_FILE;         }

[1]https://docs.spring.io/spring-boot/specification/executable-jar/jarfile-class.html

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
corechanges to coreutilschanges to utils
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Resource Loading Issues in fat jars
2 participants
@Thomas-Bergmann@aikebah

[8]ページ先頭

©2009-2025 Movatter.jp