Re: [rules-dev] validator

I'm thinking about an ontology constraint system, based around field setter validation. However I cannot decide how to handle invalid changes in a consequence or in external java code. I'll may leverage the JSR 303 - Bean Validation - http://jcp.org/en/jsr/detail?id=303. Although I have several concerns with the spec, one is that it always validates objects and passes in the field as an object - with primitive intensive stuff that can add an overhead, due to auto boxing. I'm more tempted to pass in the main Object itself and users can then use the FieldExtractor to read the field as they require, either as an Object or a primitive with full co-ercion - the FieldExtractor would be injected. Further to that I can't see how you would make the validator session aware, and doing it via constructor injection would mean a validator per session which is not desirable. I spoke to the spec lead and he mentioned using LocalThread variables. However we can have multiple sessions in the same thread, just not executing at the same time, which means the current executing session would need to set itself on that localthread variable - basically context switching, which I don't like. We should have a variable that lists the validator errors for the current working memory action phase, for user interrogation - much like Hibernate Validator (RI for JSR 303) allows you to list validation errors on a insert or update on a session. But in rule engines we have other considerations: The first fundamental question is do we allow invalid changes or do we always roll them back? My prefernce, much like a database, is the data model as seen by the engine is always valid. Now if we assume the invalid change must be rolled bank or not applied how do we expose this to the user: -Throw an exception, up to them if they catch and it will exit the engine if not caught. -Do nothing, roll back the change and continue executing the consequence as normal, they can check the validator variable if they need to. Allow for "catch" like blocks either after each modify block, or after the "then" block. Do we have one large catch block, or do we have some sort of type matching.... Currently my preference is for a "catch" block after the "then" block. I'm tempted to just have one large catch block and users can do an iteration of the validator variable doing "if" checks; we can always add in type matching later. The catch block can either resume or throw an exception; on resumption it will attempt to validate the bean again, if it's changed, if it's still invalid the process repeats. Mark _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev