After reading about the new dev tools features I decided to try it out.
I generally run my apps with mvn spring-boot:run. So after the app started up (with mvn spring-boot:run), changing some controller code and compiling the app, the app reload didn't happen as I expected. Running the app standalone, however, does reload as expected.
The docs do not mention any constraints about how your run you app. Should the Maven plugin also support devtools or will this not be supported?
Tried with 1.3.0.M1 and 1.3.0-BUILD-SNAPSHOT.
Comment From: philwebb
For the M1 release we've primarily been focusing on reload from the IDE, however, I would like to get things working from the build plugins.
How are you recompiling the application? Do you have mvn spring-boot:run in one window and you run mvn compile in another? Out of interest, what editor are you using?
Running the app standalone, however, does reload as expected
How are you running the app standalone in this case? Are you launching it from an IDE or using a different mvn goal?
It would be helpful if you could provide some more details of how you usually work. I can then try a similar workflow and try to track down why things aren't working.
Comment From: donovanmuller
I'm using IntelliJ. Below are gifcasts of the two workflows:
mvn spring-boot:run (not working)
So basically, make changes to controller and then Make project.
This compiles the changed classes to the target directory as mvn compile would do.
Standalone (working)
Comment From: philwebb
Thanks! That's a neat way to show the problem. I'll check with our resident IntelliJ/Maven expert (hi @snicoll) to see if IntelliJ writes updated classes in the /target directory or not.
Comment From: snicoll
Hey. Yes it does. Let me try to run my sample app with spring-boot:run then.
@donovanmuller out of curiosity, why are you running your app via the plugin if you can do so in the IDE directly?
Comment From: donovanmuller
There's no specific reason. Some members of the team just find it more familiar/convenient than running from within an IDE.
The issue for me is not really whether reload should work with the plugin but rather, if it can't/doesn't, there should be something in the docs that explains that. However, it would be cool if it did :)
Comment From: linead
Hey, just ran into this, I thought it was working previously but today it didn't. The problem is with the way the Restarter initializes:
protected boolean isMain(Thread thread) {
return thread.getName().equals("main")
&& thread.getContextClassLoader().getClass().getName()
.contains("AppClassLoader");
}
When I run from the main method this works fine (thread.getName is main), but using spring-boot:run I get thread.getName() == demo.DemoApplication.main()
Comment From: snicoll
Changing the name of the thread is easy and actually it feels like using the default for that would probably better so I can change that. The problem is the check for the classloader.
When fork is enabled (that's not the default value), the classloader contains indeed AppClassLoader.
When you run the app in the same process (default value unless you specified some JVM args), the classloader is java.net.URLClassLoader
I am not sure why this check is there and how we could tune it. ping @philwebb
Comment From: snicoll
@donovanmuller if you enable forking in the plugin's configuration with the latest Spring Boot snapshot it should work as expected.
I am trying to make it work for non-forked apps and I have something that works (see https://github.com/snicoll/spring-boot/commit/df26066453bfc6156ba44515bc3551b779771a49) but I have an exception on startup:
2015-07-24 10:29:28.891 INFO 25500 --- [ restartedMain] demo.DemoApplication : Started DemoApplication in 2.187 seconds (JVM running for 4.326)
[WARNING]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springframework.boot.maven.AbstractRunMojo$LaunchRunner.run(AbstractRunMojo.java:435)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.springframework.boot.devtools.restart.SilentExitExceptionHandler$SilentExitException
at org.springframework.boot.devtools.restart.SilentExitExceptionHandler.exitCurrentThread(SilentExitExceptionHandler.java:53)
at org.springframework.boot.devtools.restart.Restarter.immediateRestart(Restarter.java:174)
at org.springframework.boot.devtools.restart.Restarter.initialize(Restarter.java:153)
at org.springframework.boot.devtools.restart.Restarter.initialize(Restarter.java:521)
at org.springframework.boot.devtools.restart.Restarter.initialize(Restarter.java:499)
at org.springframework.boot.devtools.restart.Restarter.initialize(Restarter.java:464)
at org.springframework.boot.devtools.restart.RestartApplicationListener.onApplicationStartedEvent(RestartApplicationListener.java:56)
at org.springframework.boot.devtools.restart.RestartApplicationListener.onApplicationEvent(RestartApplicationListener.java:43)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:119)
at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:111)
at org.springframework.boot.context.event.EventPublishingRunListener.started(EventPublishingRunListener.java:60)
at org.springframework.boot.SpringApplicationRunListeners.started(SpringApplicationRunListeners.java:47)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:271)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:971)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:960)
at demo.DemoApplication.main(DemoApplication.java:11)
... 6 more
It looks like Maven intercepts the issue and log it automatically. Maybe we could restrict the devtools use case to forked scenario and document that accordingly.
@philwebb what do you think?
Comment From: snicoll
We decided to only support the case where the Spring Boot app works in an isolated application classloader. This should work as of M3 with Maven as long as you enable forking.
Comment From: praveen12bnitt
I use gradle and have the similar problem. Do you have a similar solution for gradle as well ?
Comment From: janowak
@praveen12bnitt actually enabling gradle deamon via:
org.gradle.daemon=true
resolved the issue for me
Comment From: 99sono
As snicoll explains, the spring boot configuration with forking enabled makes the spring boot dev tool work wonderfully. It would probably be a good idea to enhance the Spring IO jumpstart pom.xml configurations to contain some out of the profiles, such as profile id = development active by default, where the dependency on the devtools is in there along with the spring boot plugin stating that the process should be forked. Thanks for the information on this thread.
Comment From: 99sono
I must correct myself, spring-boot:run plugin does seem to have several problems. When Running the SpringBootApplication main class through the IDE, in my case Netbeans due to absurdly well implemented support for maven - not to mention a fantasitc Debugger that makes eclipse debugger look like an acient artifact - the spring boot dev tool works wonderfully. It reloads the project both when I modify classes withing the package that contained the main class, as well as classes in other sub-modules.
The same quality of container reloading does not happen when I used spring-boot:run. Here I-ve seen the following problems:
(a) The classpath dependenices are not proper. Provided dependencies are added to the classpath. While doing a spring-boot:run the tomcat container would complain trying to initiate web sockets due to lack of virtualApplicationName() in ServletContext. This was caused by spring-boot adding the gwt-user.jar to the runtime classpath, when this dependency was set as provided. To adress this one it was necessary to do
<configuration>
<fork>true</fork>
<excludes>
<exclude>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
</exclude>
</excludes>
</configuration>
(b) Second, the spring-boot dev tool was working properly doing class reloading when the app was a Single module. However, as soon as I started refactoring the pom design of the applicaton to be something of the form:
RootPom ----- API Module ---- BackendImplModule ---- GWT FrontEndModule
And then put the Main application class within the GWT FrontEndModule. What started happening as that during initial spring-boot:run the app would run fine. However, if I visited the BackendImplModule and changed some code and did a:
mvn clean install -DskipTests
, well nothing would happen.
Finally, if I went to a class in Gwt FrontEndModule and changed it the SpringBootDev tool would reload the Tomcat. But I would lose all the Rest services in the BackendImplModule.
On the other hand, when I right click in Netbeans in the MainApp class and select it to run, I am indeed able to modify classes both in the back-end and front-end package and both sides trigger container web app class loader restart.
Sometimes a bit too much :), as I do not want the gwt.client classes to trigger me a Tomcat restart, but I can live with it. ;) Since it restarts so fast for now.
Well, overall, the spring-boot:run plugin seems to have some issues, at leas for me. It is not working as accurately as a jetty plugin run, or a mvn exec rung triggered by netbeans on the application main class.
If was not packing the gwt application as a JAR file and I was building it as a WAR, I could levearage on the mvn jetty:run-explodedwar with classpath scan set on the jetty plugin to get a jrebel/spring-dev tool reload. That worked well.
In the end, it is not catastrophic if spring-boot:run is not working at 100%, as long as there is a work around solution for it. And IDE run is working quite fine up until now.
Many thanks.
Comment From: snicoll
@99sono this is issue is closed so if you want to request anything, please open a separate issue. Having said that, a few thoughts
my case Netbeans due to absurdly well implemented support for maven
Well, I have to disagree here. provided must be included. Spring Boot is the container (when it uses an embedded container) so it makes sense it includes provided dependencies. That GWT dependency of your isn't provided by the container, is it?
Well, overall, the spring-boot:run plugin seems to have some issues, at leas for me
Don't comment on closed issues then. Create one issue per topic you'd like us to look at. PR welcome as well.
Comment From: ityouknow
Very stupid, I suddenly found that spring-boot-devtools can not automatically reload, and find a lot of reasons, can not solve. I finally found a closed build automatically eclipse,When I build automatically re-open everything up and running.
Comment From: amingilani
I have the same issue. I have a new maven and spring install, and started working with Spring Boot last week, and dev tools does not reload for me.
Running OSX, have dev tools enabled from the POM file generated by Spring Initializer. Changes in class files does not do a restart.
Comment From: donovanmuller
@amingilani Just to confirm. When you change files, are you compiling/building/making after the changes. For example, if you're using Intellij, you must do Make before your app will reload... Simply changing and saving the source will not trigger a reload.
Comment From: snicoll
@amingilani see also
if you enable forking in the plugin's configuration with the latest Spring Boot snapshot it should work as expected.
Make sure fork is enabled. We should probably make that the default on start.spring.io
Comment From: amingilani
@snicoll I just added the enabled fork but modifications to myapp.WebSecurityConfig didn't reload the server. My POM file now looks like this:
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<fork>true</fork>
</configuration>
</plugin>
</plugins>
</build>
...
Sorry if I'm dragging this issue on any longer, but it's related, and I'm certain more newb like myself would be googling this without any help.
And i totally second adding it to start.spring.io
PS- Future Newbs react with a heart if this was helpful.
Comment From: acrolink
I am having the same issue..
Comment From: snicoll
@acrolink this issue is closed and "having the same issue" isn't helping. If you believe you've found a bug in Spring Boot, please create an issue with a sample and steps to reproduce. Thanks.
Comment From: razorree
having the same issue Starting StarterApplication on XXXX with PID 15200 (C:\Users\x\git\spring-boot-starter\target\classes started by x in C:\Users\x\git\spring-boot-starter) Running with Spring Boot v1.4.0.RELEASE, Spring v4.3.2.RELEASE
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<fork>true</fork>
</configuration>
</plugin>
in build/plugins, spring-boot-devtools in dependencies running app with 'mvn spring-boot:run' in one window, changing the code and 'mvn compile' in another console doesn't force boot/devtools to reload app.... if i add 'spring.devtools.restart.additional-paths=target' to application.properties boot/devtools reloads the app after compile, but it doesn't pick up the changes. what to do? how to investigate that behavior ?
it worked at the beginning, but somehow in one moment (i don't know when), just stopped
Comment From: razorree
I've found something connected to that problem. If i run app from my git repo:
DEBUG] Classpath for forked process: C:\Users\razor\git\spring-boot-starter\target\classes;........
I can see later in the logs:
2016-09-21 23:47:59.568 DEBUG 13528 --- [ restartedMain] .b.l.ClasspathLoggingApplicationListener : Application started with classpath: []
But when i copy project folder to another place (no other alterations!), after run i can see in the logs:
[DEBUG] Classpath for forked process: C:\Java\workspace_rentit\spring-boot-starter2\target\classes;C
and later:
2016-09-21 23:40:34.224 DEBUG 4060 --- [ restartedMain] .b.l.ClasspathLoggingApplicationListener : Application started with classpath: [file:/C:/Java/workspace_rentit/spring-boot-starter2/target/classes/]
Why there are differences? in second case, reloading works.
Comment From: wilkinsona
@razorree This issue is over a year old and is closed. Can you please ask questions on Stack Overflow?
Comment From: razorree
Ok. I've posted on stackoverflow http://stackoverflow.com/questions/39634422/spring-devtools-doesnt-want-to-reload-process-doesnt-pick-up-proper-classpath
Comment From: razorree
ok, strange, it was enough to change my folder name under git directory.
does it mean that my project folder shouldn't be named 'spring-boot-starter' ? is it documented 'feature' ? :)
Comment From: razorree
Ok, after fiddling with a project for a few more minutes, i've found that probably the problem is the project folder name 'spring-boot-starter' (default project name from eclipse spring boot creator?) that's why reloading in different folder worked (project folder name was different too), after changing project folder name under my git repo, reloading started to work again.
Is it documented 'feature' ? :)
looks like project's DIRECTORY shouldn't be named 'spring-boot-....' (it's not connected with the artifact name or eclipse project name)
Comment From: sergey-morenets
Hi @razorree
I can confirm that as of Spring Boot 1.4.2 dev-tools doesn't work if application folder is spring-boot.
Comment From: february
hi @sergey-morenets ! sorry, i can't understand your meaning that application folder is spring-boot. how can i find that folder?
background info: I had the same issue when develop a small spring boot (1.4.2) example by STS. according to your reply, i switch my example to 1.3.8, and then it be solved.
Comment From: sergey-morenets
You can reproduce this issue if you create Spring Boot application and name the application folder "spring-boot"
Comment From: Ilhicas
@razorree ,@sergey-morenets , thank you so much, lost a whole day figuring out why it would work in a project, and when implementing in another, ended up with no logs, It would connect to any port without any running application, and no problem, and wouldn't even try the connection or upload any file.
Comment From: nkavian
I lost 2 hours of my life because the folder name was spring-boot of an example project I was debugging. For the sake of everything holy, fix this!!!!
Comment From: wilkinsona
@nkavian Sorry for the wasted time. I understand that you're frustrated but shouting isn't going to help. The documentation lists the project names that are not eligible for restart. What fix would you like to see?
Comment From: nkavian
Thank you for the quick response.
The documentation is well written but massive. I read that chapter twice and some how I missed it till you mentioned it. My mistake there.
A desired solution would be to print into the log that devtools is disabled. That would have saved me time because I watched that output over and over to confirm devtools was present and activated once I added it to the pom.
Comment From: wilkinsona
Thanks. I've opened https://github.com/spring-projects/spring-boot/issues/23158.
Comment From: nkavian
Thank you
Comment From: vyankatesh-kulkarni
if someone is still facing issue after trying many solutions. please try deleting m2 repository and update your project. it worked for me