[ISSUE #399] Use AbstractFileStore.class for resource loading

[flying-musk]

What is the purpose of the change

This PR makes resource loading in AbstractFileStore use an explicit class reference instead of getClass().

The current code uses:

getClass().getResourceAsStream("/" + fileName)

Since AbstractFileStore is designed to be extended, this makes the lookup depend on the runtime subclass, which can introduce inheritance-related ambiguity and make the behavior less explicit for future maintenance.

Using AbstractFileStore.class.getResourceAsStream(...) makes the resource lookup context explicit and stable.

Brief changelog

• Replace getClass().getResourceAsStream("/" + fileName) with AbstractFileStore.class.getResourceAsStream("/" + fileName) in AbstractFileStore

Verifying this change

• Verified that the project still compiles after the change
• Verified by running mvn test

[flying-musk]

Gentle follow-up in case this slipped through.

This is a small, behavior-preserving cleanup that makes the resource lookup context explicit in AbstractFileStore.

I also verified the project still builds and the test suite passes locally:

• Tests run: 213
• Failures: 0
• Errors: 0
• Skipped: 0

Happy to revise if needed. Thanks!

[flying-musk]

Gentle follow-up on this PR.

@Crazylychee I noticed you’ve been active in this repository, so I wanted to kindly ask: does this change look like something that would be acceptable for the project, or is there anything else I should adjust to make the PR easier to review and merge?

This is intended as a small, behavior-preserving cleanup, and I’d be very happy to revise it if needed. Thanks for any guidance.

[oss-sentinel-ai]

Review: Approved ✅

PR: #400 — [ISSUE #399] Use AbstractFileStore.class for resource loading
Type: Bug fix (1 file, +1/-1)

Assessment

Minimal one-line fix changing the class reference used for resource loading in AbstractFileStore. Fixes #399.

Verdict

✅ Clean, targeted fix.

---

🤖 Automated review by oss-sentinel-ai

[RockteMQ-AI]

LGTM. Correct fix: using AbstractFileStore.class instead of getClass() ensures resource loading works correctly even when the class is subclassed (where getClass() would return the subclass and might not find the resource in the same classloader path).

---

Automated review by github-manager-bot