[
https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi...
]
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)