We are using Drools in a Java 11 Web application via the kie-spring library.
This library depends on xstream.
The compatibility of xstream with newer Java versions is uncertain as described in this Issue which is already 3 years old and not going to be "fixed" as far as I understand it.
Is there a plan to switch to a different underlying technology or any other changes that would move away from xstream? Or at least a way to get rid of the JVM warning and assurance that it will work with future versions?
This is an XStream problem. The very link which is shared in the original question, provide some valid solutions to avoid the mentioned XStream issue.
Is there [...] at least a way to
get rid of the JVM warning and assurance that it will work with future
versions?
As can be seen on this change https://github.com/kiegroup/drools/pull/2988#issuecomment-658079653 modifications are already underway to resolve the mentioned issue as it manifests inside the Drools project which make use of the XStream library.
So this is resolved currently for the Drools' DMN module, and Kogito; if you spotted a specific module of Drools which is not yet updated, you are encouraged to raise a JIRA.
Question on StackOverflow is one of the channel we monitor as #schrobe correctly commented here; if you need a more back/forth exchange you can also interact with Drools developers via chat or forum. All these are valid channel that we monitor as originally described in the project get help page.
I hope this fully answers your original question, let us know if you noticed the issue in other modules!
Related
We have a service that uses Drools quite heavily. Would like to improve the performance by running it on GraalVM.
Is it possible to run Drools on GraalVM without using Kogito?
Disclaimer: I'm one of the Drools developers
It's definitely possible, as you've already notice, we do indeed support native image compilation with our Quarkus backend, but it'll require you to write you some code, there's no such possibility in the current codebase.
Please note that only the executable model will be supported with the static component injection (the drools-core-static module in Kogito)
Is there a reason why you don't want to use Kogito though? We are really interested. Please join our community channels or the mailing list if you want to share your feedbacks, as SO is not the best platform for it.
Thanks for your support
I am trying to figure out if the IBM Persistent Reusable JVM is still relevant and supported with latest Java versions. There is very little I find when searching on internet. There is just this document that talks about it and it looks very old, it refers to JDK 1.4.2 and mentions that the -Xresettable feature is deprecated. I have tried using -Xresettable with JDK 8 and that failed as expected, that however doesn't mean the entire concept doesn't work and hence the question. We have a requirement where we want to invoke a JVM from C code and keep the JVM around and not destroy it for further request processing. Since the OS is z/OS which runs IBM JVM, I am trying to understand if the Persistent Reusable JVM is an option though my hopes are dim. If anyone knows about it, please let me know.
If it turns out to be outdated, I will evaluate other options of keeping a JVM alive, but that's secondary right now.
I believe it is as you fear: the Persistent Resusable JVM feature never made it past Java 1.4.2.
If you haven't checked it out yet, look at the -Xshareclasses JVM option available in the more current IBM Java releases. It creates a shared memory cache of user and system classes, mostly with no impact to applications - somewhat similar in result to what persistent reusable JVM did, but without the side-effects.
Several links show that https://code.google.com/p/concurrentlinkedhashmap/ has been ported to Guava, but I can not find the corresponding API in Guava.
Can anybody show me an example to build a ConcurrentLinkedHashmap using Guava ?
Thanks!
ConcurrentLinkedHashmap API wasn't ported to Guava 1:1, but some solutions from CLHM were used in MapMaker and Cache (with CacheBuilder).
ConcurrentLinkedHashmap's author Ben Manes answers a question which may clarify your doubts: What does it mean that ConcurrentLinkedHashMap has been integrated into Guava?:
Guava is the long term replacement and most of the time you should use it. The history is that ConcurrentLinkedHashMap figured out the algorithms, Guava subsumed it, and then focused on adding features.
I think it's also important to note that he's currently writing another library which may suit your needs:
Caffeine is a Java 8 rewrite of Guava's cache. It tries to provide the best of ConcurrentLinkedHashMap and Guava, modernized with Java 8, and adopting the techniques that I've learned since those previous projects.
We are upgrading our application from drools 5.0.1 to drools 6.0.1 Final. I noticed there are some API changes. Many classes that used to be in org.drools appear to be now in org.drools.core. Also, the class DebugRuleFlowEventListener appears to no longer exist.
My question is: is there a documentation somewhere explaining the API differences between the two versions? Unless I'm missing something, it seems like they are significant and should be documented. Also, thought I was tasked with the upgrade I wasn't the one who developed so I'm far from being an expert on drools.
If there is no such documentation - can anyone advise what to do about DebugRuleflowEventListener?
Thanks, Thomas
A big focus for 6.0 was streamlining the build, deploy and loading(utilization) aspects of the system. Building and deploying now align with Maven and the utilization is now convention and configuration oriented, instead of programmatic, with sane default to minimise the configuration.
Two primary distributions consist of:
KIE Drools Workbench
Drools Editors, for rules and supporting assets.
jBPM Designer, for Rule Flow and supporting assets.
KIE Workbench
Drools Editors, for rules and supporting assets.
jBPM Designer, for BPMN2 and supporting assets.
jBPM Console, runtime and Human Task support.
jBPM Form Builder.
BAM.
Regarding API would suggest looking at OFFICIAL DOCS
There are three debug classes:
DebugAgendaEventListener
DebugRuleRuntimeEventListener
DebugWorkingMemoryEventListener
Some of the methods afterRuleFlowGroupActivated(RuleFlowGroupActivatedEvent event) and afterRuleFlowGroupDeactivated(RuleFlowGroupDeactivatedEvent event) which existed in DebugRuleFlowEventListener are moved to DebugAgendaEventListener
Hoping was able to help to some extent.
Cheers !!
I'm currently exploring similar alternatives to Ruby on Rails, and have been considering Playframework using Scala (cuz I'm not fond of Java).
Problem is, even if the default sample of application works very fine, everytime I try doing actual work with Playframework, it end up with it not answering HTTP requests.
It compiles after the first request, but doesn't answer it.
Then it ignores every other request (not even re-compiling when I changed stuff).
It does kick out an user typing an incorrect request, but it never times you out if the request is correct.
What is this ?
I'm using Playframework 1.2.3 with the Scala module. Is there any way to get a better insight at what's happening ?
So it never times out, isn't it? as if it was compiling forever?
If yes, maybe you have problems with the Scala compiler which is slower than Java compiler and requires more stack. Generally if you don't have enough stack, it should crash with a StackOverflow.
YOu can try to run play with "play run -Xss1024k" for example to increase the stack size.
If you get empty answer, it means the problem is somewhere else like routes or bad object returned from your controller.
Anyway, Play-Scala is still young and in evolution so it's not a reliable solution for an entreprise solution if you're not yet an expert in Scala and don't already know Play IMO. It's already robust and stable but not well documented and as complete as Java version.
Finally, you say you're not found of Java and it's something I can understand but you should really give a try to Play/Java since it's completely different from any other Java stuff. I can say that because I'm an old Java developer and find the language getting a bit outdated in its syntax and basic features. I don't really like Java EE web frameworks in general because they are not really productive and user-friendly. When I found Play more than one year ago, it was like a breath of air for me. You get the best of modern web frameworks and the best of the Java world which are all the robust and approved entreprise tools coming from opensource. I've never been deceived by it since this time.