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

Devtools reload seems to lose application properties on first run in Eclipse #20894

Closed
leccelecce opened this issue Apr 9, 2020 · 6 comments
Closed
Labels
for: external-project For an external project and not something we can fix

Comments

@leccelecce
Copy link

leccelecce commented Apr 9, 2020

Spring Boot 2.3 M3 & M4

My application previously had no issues on Boot 2.1 or 2.2. Since using the Boot milestones, I intermittently see the below issue when making a change to a Java object that triggers a reload. I'm using Eclipse 2020-03 (with the Java 14 patch) with Build Automatically on.

I have a suspicion that Boot is losing application.properties during the reload, because a) if the datasource URL wasn't defined as it complains the app wouldn't be able to start the first time (before the object change), b) in the log below, the Boot ascii art banner appears, yet I have spring.main.banner-mode=off in my application.properties and c) because I also get a tonne of messages about Spring Data Redis repository scanning, and I have spring.data.redis.repositories.enabled=false.

I'm running an application.properties file with most of my configuration, and an application-dev.properties file with some local overrides. At the start log for both the initial and reload startup, I do see "The following profiles are active: dev" as I expect.

For a final bit of weirdness, sometimes after the failed startup it then immediately tries to reload again, and sometimes succeeds, but sometimes doesn't (will try and capture this more).

Attached is my startup log during an occurrence of this.
Boot-Log.txt

It appears to only happen the first time I've started Eclipse - stopping the process and then starting again seems to prevent it. However I'm not sure why Eclipse would be relevant to Boot finding it's properties. My Eclipse debug profile applies -Dspring.profiles.active=dev.

<reload initiated>
2020-04-09T08:13:58,119 INFO  [Thread-1] [] c.z.h.HikariDataSource: HikariPool-1 - Shutdown initiated...
2020-04-09T08:13:58,130 INFO  [Thread-1] [] c.z.h.HikariDataSource: HikariPool-1 - Shutdown completed.

...(ascii art banner removed)...

2020-04-09 08:13:58.448  INFO 55412 --- [  restartedMain] c.e.w.Application                        : Starting Application on JAMES-SURFACE with PID 55412 (C:\Users\james\eclipse-workspace-ecv\ecv-webapp\target\classes started by james in C:\Users\james\eclipse-workspace-ecv\ecv-webapp)
2020-04-09 08:13:58.449  INFO 55412 --- [  restartedMain] c.e.w.Application                        : The following profiles are active: dev
2020-04-09 08:13:58.880  INFO 55412 --- [  restartedMain] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
2020-04-09 08:13:58.880  INFO 55412 --- [  restartedMain] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFERRED mode.
2020-04-09 08:13:59.040  INFO 55412 --- [  restartedMain] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 160ms. Found 38 JPA repository interfaces.
2020-04-09 08:13:59.078  INFO 55412 --- [  restartedMain] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
2020-04-09 08:13:59.079  INFO 55412 --- [  restartedMain] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data Redis repositories in DEFAULT mode.

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured.

Reason: Failed to determine a suitable driver class

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

It appears to only happen the first time I've started Eclipse - stopping the process and then starting again seems to prevent it. However I'm not sure why Eclipse would be relevant to Boot finding it's properties.

Eclipse is responsible for compiling and copying the files into the location from which Spring Boot reads them. It would appear that DevTools is seeing this location at a point where the application.properties file does not exist.

Can you please try tuning the file system watcher's configuration. In particular, an increased quiet period may help.

@wilkinsona wilkinsona added the status: waiting-for-feedback We need additional information before we can continue label Apr 9, 2020
@leccelecce
Copy link
Author

leccelecce commented Apr 9, 2020

Many thanks @wilkinsona, this seems to have fixed it. I've tested with:

spring.devtools.restart.poll-interval=3s (Default 1s)
spring.devtools.restart.quiet-period=2s (default 0.4s)

And it looks to be working now. Interesting now you've pointed me in the direction, when I change a Java object on first load Eclipse does show it's "Building..." progress bar for several seconds. When I change the same Java object again (e.g. by adding a line int i = 1; then removing it), it compiles far quicker, so presumably it does something like recompile the whole project on first start.

Have there been any changes in Boot 2.3 that might be relevant to this - I ask because I recently upgraded to Eclipse 2020-03 so it's possible it's something they changed there, in which case I could raise it with them. It doesn't look like FileSystemWatcher has seen any changes. Although the solution you've given me works, it's a bit of a shame to add ~5 seconds to every restart.

On a side note, I did read the DevTools documentation you linked to before posting. However, I missed the Configuring File System Watcher section because it comes under Remote Applications, which didn't appear relevant to me. Possibly this could be tweaked to make it clearer that these settings are relevant for locally run applications as well.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Apr 9, 2020
@leccelecce
Copy link
Author

A bit more info. I set a breakpoint in FileSystemWatcher to look at the changeSet that it's identified. Interestingly, you can see it's picked up not just the Java object I changed, but also the .properties files.

I'm not sure why this is happening - will try to investigate further to see if they're being rewritten by Boot or genuinely changed by Eclipse.

image

@wilkinsona
Copy link
Member

On a side note, I did read the DevTools documentation you linked to before posting. However, I missed the Configuring File System Watcher section because it comes under Remote Applications, which didn't appear relevant to me. Possibly this could be tweaked to make it clearer that these settings are relevant for locally run applications as well.

Yeah, that section's in the wrong place. I didn't notice when I linked to it earlier as I searched for the property name and then linked to the section without spotting the wider context. I've opened an issue to relocate it.

I'm not sure why this is happening - will try to investigate further to see if they're being rewritten by Boot or genuinely changed by Eclipse.

Boot doesn't rewrite anything. It relies entirely on the IDE to do so as you make changes.

Have there been any changes in Boot 2.3 that might be relevant to this - I ask because I recently upgraded to Eclipse 2020-03 so it's possible it's something they changed there, in which case I could raise it with them.

We haven't changed anything in this area as far as I can recall and the git history tells the same story. I would guess that the change in behaviour is due to something in Eclipse 2020-03. It would be interesting to know what behaviour you see with 2020-03 and Boot 2.2.x.

@leccelecce
Copy link
Author

I've just managed to reproduce this in Boot 2.2.6, so it's not a new issue. Apologies, I should have taken into account the Eclipse upgrade as well (had to upgrade to Eclipse 2020-03 at the same time as Boot 2.3 to get Java 14 support, which I now see is backported to 2.2.6).

I will have a dig around Eclipse to try and find out what's changed there, and if they're doing something funny will raise it with them.

Thanks for the rapid investigation on this.

@snicoll
Copy link
Member

snicoll commented Apr 9, 2020

Thanks for the follow-up.

@snicoll snicoll closed this as completed Apr 9, 2020
@snicoll snicoll added for: external-project For an external project and not something we can fix and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: external-project For an external project and not something we can fix
Projects
None yet
Development

No branches or pull requests

4 participants