Remote Spring Boot devtools unable to restart application if a dependency has autowire candidates that the main application uses

[duncan-at-hiveit]

Hi there,

We have a situation where we have a multi module Gradle project that has shared Spring components, but hot restart fails due to classloader issues. This is with Spring Boot 1.5.1.RELEASE.

FYI I've put together an example of the error we're having here

Within our project we have some shared @Services that are used by several web applications. These shared services live in their own module within the main project structure and have a bunch of @Service classes within it.

A web application will be in a separate module within the main project structure and will have a "compile project" dependency on the shared services module. It then has @Controller controllers that use the @Service services from the dependency. The web application is build with bootRepackage and run as a standalone jar, with the shared services module as a jar within BOOT-INF/lib.

The problem occurs when updating anything in the shared services module that causes a hot reload. If that happens, the remote hot reload process (using RemoteSpringApplication) tells the RestartServer to do a reload of the classes only within the shared services jar. The newly reloaded @Services are now available in the RestartClassLoader. When Spring fires up to do the hot restart process, it is unable to wire up the @Controllers with the @Services, because the @Controllers are in the LauchedURLClassLoader but the @Services are now in the RestartClassLoader, and so when it's trying to wire up a controller with a particular @Service class it is unable to find it because it's no longer in the same classloader as the @Controller.

It seems like it would be good if there was some flag to say to restart everything that can be reloadable at the same time, so that you don't end up having some potentially reloadable stuff in one loader and other potentially reloadable stuff in the the loader.

Many thanks for your time and help,
Duncan

[snicoll]

What you are describing is explicitly described in the documentation so please review that and update your project accordingly.

[duncan-at-hiveit]

Hi Stephane,

Thanks for the update. I do have the entry:

restart.include.hotdeployjars=/hotreloaddependency\\.jar

in src/main/resources/META-INF/spring-devtools.properties, which matches the name of the jar that the dependency produces. Have I miscofigured this somehow?

Many thanks,
Duncan

[duncan-at-hiveit]

Hi there Stephane,

Thanks for reopening. I suspect that the issue may be related to the remote nature of using devtools. For instance, when running bootRun directly, I see logging like:

15:41:50.761 [QUIET] [system.out] 15:41:50.760 [main] DEBUG org.springframework.boot.devtools.settings.DevToolsSettings - Included patterns for restart : [/hotreloaddependency.jar]
15:41:50.762 [QUIET] [system.out] 15:41:50.761 [main] DEBUG org.springframework.boot.devtools.settings.DevToolsSettings - Excluded patterns for restart : [/spring-boot-starter/target/classes/, /spring-boot-au

When firing up the jar remotely I see no such logging. Obviously devtools is there because we're able to break it with redeploys, but I wonder if DevToolsSettings is never invoked?

Many thanks,
Duncan

[snicoll]

I have the same analysis and I can't see how this would ever work remotely actually. But looking at the documentation, it isn't clear either it would not be supported so I've reopened it to clarify that.

[duncan-at-hiveit]

Thanks!

[duncan-at-hiveit]

FYI yesterday I raised a similar question in Stack Overflow regarding the documentation of local versus remote capabilities, so if you're able to provide clarification here I will update my post at:

http://stackoverflow.com/questions/42276108/limitations-of-spring-boot-devtools-with-a-remote-application

Thanks,
Duncan