Okay, now I understand what is going on... Either someone is pretending to be Mark Proctor or Mark and Adrian are long time adversaries. If the situation is the former, then I suggest we find out how to stop it... If it is the latter, then I think that these personal wars should be waged somewhere else.
IMHO! - Dave -----Original Message----- From: Mark Proctor [mailto:[EMAIL PROTECTED] Sent: Thursday, November 10, 2005 6:58 AM To: [email protected] Subject: Re: [drools-user] input validation in rules used by JSR-94 clients If you are going to assert a logging instance I suggest you go outside put your head on the road just after the curb and wait for a bus to come along - will be less painfull. If you can't use application data, the maybe just a static reference to an imported class? Mark Adrian Bigland wrote: > Thanks for the reply, Mark. > > I didn't want to use application data - I want my clients to use the > same code for any JSR-94 compliant rule engine. My immediate aim is to > try out several implementations with my application, to run > performance tests and just to see the different rulefile styles. > JRules, for example, doesn't have any way (that I've come across so > far) to hook up rule execution provider property map settings to its > rule parameter system (which seems to me to be the equivalent of application data in JRules). > > So I need to rely on asserting things into working memory for that reason. > Anyway, validation would still be a problem with application data, > wouldn't it? Maybe even worse because at least a rule that only fires > if the logger is there can never throw a NullPointerException because it is missing... > > > > > Mark Proctor > <[EMAIL PROTECTED] To: [email protected] > us.org> cc: > Subject: Re: [drools-user] input validation in rules used by JSR-94 clients > 10/11/2005 13:43 > Please respond > to user > > > > > > > Don't put the logger in as a fact use ApplicationData to inject it > into conditions and consequences without it having to be in the WorkingMemory. > > Mark > Adrian Bigland wrote: > >> Hi all, >> >> I'm writing Drools into my application through the JSR-94 API, and >> I've been considering how to deal with required inputs. >> >> For example, I want to add a logging component to working memory so >> that >> > I > >> can create a good explanation of the results of the rule session. I >> need >> > to > >> match this as a parameter to make it available in the rule consequence. >> > If > >> the user doesn't add a logger, none of the logging rules will fire. >> It would be better if I could fire a rule that returned some kind of >> well-defined error state if the logger is missing, for example >> asserting >> > an > >> error object or something. >> >> There doesn't seem to be a way of matching an absence of an instance >> of a class in the rules - in fact, the meaning of such a rule is not >> entirely clear. >> >> One way I tried to do this was to count the number of loggers - and >> > assert > >> the count as a fact. A rule can match this fact and assert an error. >> The only trouble was that I had to implement modes and mode changes >> in the rules as well; the scaffolding code was large enough that it >> destroys the most important benefits of using a rule engine to begin with, i.e. >> recording business logic in a concise and manageable way. >> >> Has anyone tackled this? Am I missing a better approach? >> >> I am currently thinking of simply unit testing the clients to check >> that the inputs match the current version of the rules, and >> programming the clients defensively. >> >> This also started me thinking about strategies to manage change in rules. >> How do you make sure that old clients get a decent error state if >> they >> > run > >> rules that they no longer know how to make good inputs for. Here I >> > decided > >> that the best approach was a good versioning system, with major >> version changes indicating that a client is no longer 'binary >> compatible' with a set of rules. Whatever you do, because rules and >> code are separate, you will always have to be careful when deploying >> them that the clients can call rules properly, and that the results >> still mean the same thing that the client thinks they mean... >> >> >> >> ********************************************************************* >> * This e-mail and any attachment is intended for the named >> addressee(s) >> > only, or person authorised to receive it on their behalf. The content > should be treated as confidential and the recipient may not disclose > this message or any attachment to anyone else without authorisation. > Unauthorised use, copying or disclosure may be unlawful. If this > transmission is received in error please notify the sender immediately > and delete this message from your e-mail system. Any view expressed by > the sender of this message or any attachment may be personal and may > not represent the view held by First Choice Holidays PLC and its subsidiaries. > All electronic transmissions to and from First Choice are recorded, > may be monitored and are scanned for viruses and content. E-mails > containing viruses will be deleted without notification. Whilst we > maintain virus checks on inbound e-mails we accept no liability for > viruses or other material introduced with this message. > >> All companies form part of the First Choice Holidays PLC group of >> > companies. > >> First Choice Holidays PLC Company Registration No: 48967 (England) >> >> Registered Office: First Choice House, London Road, Crawley, >> WestSussex >> > RH10 9GX > >> ********************************************************************* >> * >> >> >> >> >> > > > > > > > >
