Skip to content

spring-boot:run uses the wrong default working directory for a forked JVM #16811

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

Closed
drahkrub opened this issue May 9, 2019 · 6 comments
Closed
Assignees
Labels
type: bug A general bug
Milestone

Comments

@drahkrub
Copy link

drahkrub commented May 9, 2019

I would like to migrate some ancient multi module spring application containing lots of JSPs to spring-boot.

I know https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-jsp-limitations but some preceding (single module) tests all ran fine.

Since I would like to preserve the multi module structure, I first ran into a problem, which fortunately has been solved here: #3436

So, I can start my multi module project with the usual mvn spring-boot:run but unfortunately JSPs can not be served this way!

I created a simple example project https://github.com/drahkrub/spring-boot-multi-module-jsp (a simplified version of https://github.com/spring-projects/spring-boot/tree/v2.1.4.RELEASE/spring-boot-samples/spring-boot-sample-tomcat-jsp turned into a multi module project) with the following minimalistic content:

.
├── pom.xml
└── webapp
    ├── pom.xml
    └── src
        └── main
            ├── java
            │   └── de
            │       └── idon
            │           └── sandbox
            │               ├── SandboxJspApplication.java
            │               └── WelcomeController.java
            ├── resources
            │   └── application.properties
            └── webapp
                └── WEB-INF
                    └── jsp
                        └── welcome.jsp

Now, if started with mvn spring-boot:run (or mvn -pl webapp -am spring-boot:run) http://localhost:8080/ gives

There was an unexpected error (type=Not Found, status=404).
/WEB-INF/jsp/welcome.jsp

But if running the WAR file, i.e. mvn clean package followed by

java -jar webapp/target/spring-boot-multi-module-jsp-webapp-0.0.1-SNAPSHOT.war

http://localhost:8080 works as expected.

I noticed that mvn spring-boot:run also works if the content of webapp/src/main/webapp is copied in a folder src/main/webapp in the parent module (obviously the place expected by the spring-boot maven plugin if operating in single module mode).

Is there a clean solution for this problem?

I tried some of the parameters described here but maybe I've used them incorrectly or tried the wrong ones... ;-)

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 9, 2019
@wilkinsona
Copy link
Member

Thanks for the sample.

This looks like a bug in Boot's Maven plugin to me. By default, the run goal's default working directory should be the basedir of the Maven project being built but that does not appear to be the case. Instead, the working directory is the directory in which Maven was invoked. You can work around the problem by adding the following to the configuration of spring-boot-maven-plugin in your webapp project:

<workingDirectory>${basedir}</workingDirectory>

@wilkinsona wilkinsona added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels May 9, 2019
@wilkinsona wilkinsona added this to the 2.1.x milestone May 9, 2019
@drahkrub
Copy link
Author

drahkrub commented May 10, 2019

@wilkinsona Thanks for the quick response and the workaround! I'd have bet I tried adding <workingDirectory>${basedir}</workingDirectory>... ;-)

@drahkrub

This comment has been minimized.

@drahkrub

This comment has been minimized.

@drahkrub

This comment has been minimized.

@snicoll

This comment has been minimized.

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

No branches or pull requests

4 participants