By your description, they look like problems, so please open a ticket
for them.
Edson
2011/12/28 Miles Wen
> Hi all,
> I'm using drools 5.3.0.Final.And I think I found two possibly bugs:
>
> 1): drl compilation failed when encountering multiple continuous '!'
> (a.k.a 'not' operator)s
Thanks everyone for the responses. Maciej I did in fact try declaring the
class within a package and saw similar oddities. Thanks for the excellent
assistance.
Wolfgang, I have filed JIRA JBRULES-3322 for this issue.
https://issues.jboss.org/browse/JBRULES-3322
Thanks again for the assistance
I have been experimenting with using the same set of rules for both record
validation (when a completed record come to us from a 3rd party) and field
validation (when the record is filled out via a web app). I don't want to
have two separate sets of rule validation (twice the maintenance, twice th
Hi Davide,
The creation of the Java annotation fixed the Problem. I can know access the
classes with the correct annotation in Java.
Thanks!
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-Access-metadata-of-declared-drools-expert-types-in-Java-tp3619839p3620794.h
I have reduced my problem to a minimal example:
- I use a pseudo clock and stream mode processing
- The events are inserted using a succession of advanceTime(), insert(),
fireAllRules()
- I have three events named: Thief, SwitchOn and SwitchOff
- I have three rules similar to:
rule "det
+1 to Wolfwang solution
The other alternative is to share information between the two nodes
using an extra master node that keeps a global status (high-level
information) to know when to update each of the low-level nodes that
handle more specific information.
On Fri, Dec 30, 2011 at 5:09 AM, Wolf
This is a bug. Please submit a JIRA.
In spite of all the fixes that have been made, using dialect "mvel" is
still risky.
In this case, it would appear that the WM insert from inside the called
function is somehow hidden from the Engine due to the RHS being evaluated
in a MVEL context. You can eas
The standard proposal for this kind of problem is to route messages
to processing nodes according to some account key function, e.g. mod 2.
Thus, all state handling for one account is done in one node.
-W
On 29/12/2011, gboro54 wrote:
> Messages may or may not update the same context depending on
