Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MissingLocaleException when using Dummy4j in a Spring Boot jar #38

Open
little-pinecone opened this issue May 25, 2021 · 1 comment
Open

Comments

@little-pinecone
Copy link
Collaborator

Example application: efficient-mvp-example

After building application with the following command:

mvn clean package && java -jar -Dspring.profiles.active=dev,init target/efficient-mvp-example-0.0.1-SNAPSHOT.jar 

and making the http://localhost:8080/api/init?seed=1&how-many-books=100 request I'm getting MissingLocaleException.

The logs show:
Loading definitions from: [BOOT-INF/classes/dummy4j/en/book.yml]
instead of
Loading definitions from: [dummy4j/en/book.yml, …]

Adding another condition specifically for Spring Boot projects in YamlFileLoader::isInAllowedPath seems to fix the problem, but there must be a better way that doesn't require hardcoding:

    private boolean isInAllowedPath(String resource, List<String> paths) {
        boolean isInAllowedPath = false;
        for (String path : paths) {
            if (resource.startsWith(path) || resource.startsWith("BOOT-INF/classes/" + path)) {
                isInAllowedPath = true;
                break;
            }
        }

        return isInAllowedPath;
    }

Useful links:
Resource pattern filter for complete resource path #148

daniel-frak added a commit that referenced this issue Jun 7, 2021
@daniel-frak
Copy link
Owner

Good find, there are some issues in versions 0.7.2 and earlier when it comes to using Dummy4j in jars.

I have fixed this in version 0.7.3, at least mostly. There should now be no issues when using Dummy4j in Spring Boot. Unfortunately, I had to hardcode the "BOOT-INF/classes/" prefix, as I could not figure out a better solution for the time being.

While this issue is fixed, I will leave this issue open for now, to act as a reminder that the resource loading code needs some refactoring.

As for the refactoring, an idea to pursue could be to use the ResourceStreamProvider::get method to get a list of all files in the client's classpath (and somehow try to get their prefix), but that's for another day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants