Spring devtools classloader limitations [SWF-1690]

[spring-operator]

Alvise Vitturi opened SWF-1690 and commented

With spring boot devtools there are known limitations:

You may need to use Spring’s ConfigurableObjectInputStream in combination with Thread.currentThread().getContextClassLoader().

The class SerializedFlowExecutionSnapshot use the base classloader instead of the restart classloader

---

Affects: 2.4.4

Issue Links:

• Web Flow Spring Boot Dev Tools don't play nice [SWF-1696] #873 Web Flow Spring Boot Dev Tools don't play nice
  ("is duplicated by")

9 votes, 7 watchers

[spring-operator]

Rossen Stoyanchev commented

I'll consider this although I'm concerned about potential side effects in more traditional application servers.

Phil Webb what's your take on this?

[spring-operator]

Phil Webb commented

I think Rob changed something in Spring Session in a similar way to accommodate Devtools. I'm not sure what the impact will be on traditional app servers. My guess is that they will be fine but perhaps it should be an opt-in setting.

[spring-operator]

David Melia commented

Hi,

I have a Spring Boot example on https://bitbucket.org/davidmelia/spring-boot-webflow-issue to illustrate this issue.

Thanks

[spring-operator]

David Melia commented

@Rossen Stoyanchev I tried to test this today by pulling in

<dependency>
    <groupId>org.springframework.webflow</groupId>
    <artifactId>spring-webflow</artifactId>
    <version>2.4.5.BUILD-SNAPSHOT</version>
</dependency>

however it didn't solve my problem in https://bitbucket.org/davidmelia/spring-boot-webflow-issue

Any ideas??

Thanks

[spring-operator]

Rossen Stoyanchev commented

Hm, no idea actually. I simply implemented the suggestion. Were you able to confirm the fix is indeed in place and being used, e.g. stepping through with a debugger?

[spring-operator]

Rossen Stoyanchev commented

David Melia thanks for the sample app. On closer look there are a number of places where a ClassLoader is used that may need to change. Modifying the one in FlowModelFlowBuilder#toClass does the trick for your example but overall this is going to take broader changes and more testing after which there is potential for regressions. So I am going to move the target to 2.5 only and revert the change made for 2.4.5.

[spring-operator]

Rossen Stoyanchev commented

I experimented with the attached example using Spring Web Flow 2.5.0.BUILD-SNAPSHOT and Spring Boot 2.0.0.RC1 and did not run into any issues. I made changes to DaveFlowController and upon recompiling the application reloads as expected and the functionality changes. For changes to the flow definition, you need getFlowBuilderServicesBuilder().setDevelopmentMode(true).

If this still doesn't work for you please be more specific about the actual problem.

[spring-operator]

Roland Mueller commented

Why wasn't the opt-in implemented as suggested by Phil Webb ?

This change breaks our application since we are using spring-webflow in OSGI bundles and these need the BundleClassLoader from Apache Felix. This is now replaced by Tomcats WebappClassLoader which leads to ClassNotFoundExceptions.

It looks like the change here seems some Spring Boot specific hack, now others like us need to implement hacks to reverse the change... :(

[spring-operator]

Roland Mueller commented

See comment above, the change introduces bugs.