[jboss-jira] [JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools

[Andy Wilkinson (Jira)]

    [ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727467#comment-13727467 ] 

Andy Wilkinson commented on DROOLS-1540:
----------------------------------------

I've spent a bit of time stepping through the sample and the root of the problem seems to lie in a combination of {{ProjectClassLoader}} and its delegation model and the split {{ClassLoader}} arrangement that Spring Boot's DevTools uses.

When DevTools is added to the class path, the application's own classes are loaded by the {{RestartClassLoader}} whereas classes from any of the application's dependencies are loaded by the app class loader. The {{RestartClassLoader}} uses the app class loader as its parent. The application's own classes remain visible to the app class loader so it's important that the {{RestartClassLoader}} is used when loading application classes. If it's skipped and an attempt is made to load one of the application's classes using the app class loader, two different versions of the application's class will be loaded. This is what is happening with Drools and is where the {{ProjectClassLoader}} comes into play.

{{ProjectClassLoader}} has a non-null {{droolsClassLoader}} which is the app class loader. {{ProjectClassLoader}}'s parent is the {{RestartClassLoader}}. When available, {{internalLoadClass}} prefers {{droolsClassLoader}}. This results in application classes being loaded by the app class loader rather than the {{RestartClassLoader}}. If {{ProjectClassLoader}} had no {{droolsClassLoader}} or if it didn't use {{droolsClassLoader}} to load non-Drools classes, standard {{ClassLoader}} delegation would result in {{RestartClassLoader}} being used to load the application class and the problem would not occur.

I don't know enough about Drools to identify a reasonable step forward or to be confident that the analysis above is particularly useful. It looks like a {{ProjectClassLoader}} with a {{null}} {{droolsClassLoader}} or that does not delegate to {{droolsClassLoader}} when loading non-Drools classes would solve this particular problem but it may well introduce another one.

I'm happy to help in trying to figure this out if you think there's anything useful in the above.



> Drools does not work with spring-boot-devtools
> ----------------------------------------------
>
>                 Key: DROOLS-1540
>                 URL: https://issues.jboss.org/browse/DROOLS-1540
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.5.0.Final
>            Reporter: G Xiong
>            Assignee: Mario Fusco
>            Priority: Critical
>         Attachments: complete.zip
>
>
> Drools does work with spring-boot-devtools.
> If you add in pom.xml the following, no rules will be fired in Drools.
> 		<dependency>
> 			<groupId>org.springframework.boot</groupId>
> 			<artifactId>spring-boot-devtools</artifactId>
> 		</dependency>
> if you comment out this, then rules will be fired in Drools.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)