-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EasyRules with Guice #61
Comments
Hi, I'm sorry for the late reply. Probably related to issue 56. Will look into this asap. Kind regards |
For now i am creating a rules engine per thread. |
Hi, I don't know if you've already seen question 6 of the FAQ. Since the rules engine is stateful (its state is the set of registered rules) and rules are also stateful (their state is the data they operate on), they are not thread safe.
This is the way to go as suggested in the faq.
What do you think about it? I would love to hear your feedback! Kind regards |
We wanted something light and this fit our needs, our rules are not very complex and other rule engines seem too complex for the task at hand. We currently have it running in our dev environments, and plan to push it to production soon. |
Glad to hear that. If you have any question, I would love to help. |
V3 has been published with a new working memory abstraction. This makes the rules and the rules engine stateless. Your integration with Guice should be easier now and you should have no issue with your use case. You can see an example of the new API in issue #37 Kind regards |
We just started experimenting with EasyRules, our application uses Guice for DI.
On app launch we create a singleton instance of RulesEngine and register all rules (singletons) with the engine.
Each rule requires some data which in turn decides if some action needs to be done, this data keeps changing. So I have added a
Before firing the rules we update the data as mentioned in
We are facing a problem where the rule data is overwritten by the next web service call, This happens in our integration tests when we test our api asynchronously.
Is there a way to prevent this? Is this related to #56?
The text was updated successfully, but these errors were encountered: