Yes, you could register your static rules in the afterStartup method on a
RuleProvider. (That's exactly what that method is for.)
E.g. the handler in the logic module that handles dynamically-defined rules
in groovy or java does:
/**
* @see org.openmrs.logic.rule.provider.AbstractRuleProvider#afterStartup()
*/
@Override
public void afterStartup() {
TokenService tokenService = Context.getService(TokenService.class);
RuleDefinitionService service =
Context.getService(RuleDefinitionService.class);
for (RuleDefinition rd : service.getAllRuleDefinitions()) {
tokenService.registerToken(rd.getName(), this,
rd.getId().toString());
}
}
Also, do make sure you extend AbstractRuleProvider rather than just
implementing RuleProvider, in case that interface ends up getting methods
added later.
-Darius
On Thu, Sep 1, 2011 at 8:15 AM, McKee, Steven Jay <[email protected]> wrote:
> I can see this approach working well for our dynamic class loading:****
>
> ** **
>
> **1. **The class loader task looks for new classes.****
>
> **2. **Once found, the rules get registered to our DSS rule
> provider.****
>
> **3. **The DSS rule provider would use our compiling classloader to
> locate the file in the “getRule” method.****
>
> ** **
>
> We still, however, have the issue of our static rules in some of our
> modules. We want to be able to use these on the fly, so how would be
> initially get these rules registered? Would be have to write some sort of
> task to do this on startup? Is there anything in logic that provides us a
> way of doing this? I noticed there’s an “afterStartup” method in the
> RuleProvider interface. What exactly is this used for?****
>
> ** **
>
> Thanks,****
>
> Steve****
>
> ** **
>
> ** **
>
> *From:* Darius Jazayeri [mailto:[email protected]]
> *Sent:* Wednesday, August 31, 2011 5:34 PM
> *To:* McKee, Steven Jay; dev
>
> *Cc:* Dugan, Tammy Marie
> *Subject:* Re: New LogicService method****
>
> ** **
>
> Moving this to the developers list.****
>
> ** **
>
> The way this is supposed to work is that if you have a rule (YourRule.java)
> and you want it to be accessible as the token "Your Rule", then you need to
> do something like this:****
>
> TokenService.registerToken("Your Rule", chicaRuleProvider,
> "InternalUniqueIdOfYourRule");****
>
> ** **
>
> Then when LogicService.getRule("Your Rule") is called, that will delegate
> to:****
>
> chicaRuleProvider.getRule("InternalUniqueIdOfYourRule");****
>
> ** **
>
> Presumably you have a RuleProvider in your module already? (Even if you're
> bypassing LanguageHandler, I think RuleProvider is necessary...)****
>
> ** **
>
> The logic infrastructure will cache these rules (since they may be
> expensive to compile) so if you want it to forget a cached value, you'd do:
> ****
>
> TokenService.notifyRuleDefinitionChanged("Your Rule");****
>
> ** **
>
> It seems like these methods should be sufficient for what you're trying to
> do.****
>
> ** **
>
> (Adding a method to LogicService is pretty significant to do, because
> that's a change to the core api, which requires simultaneous releases of new
> versions of 1.6.x, 1.7.x, and 1.8.x, to support the new logic module. It's
> possible that we end up doing this, but it can't happen quickly.)****
>
> ** **
>
> -Darius****
>
> ** **
>
> On Tue, Aug 30, 2011 at 2:42 PM, McKee, Steven Jay <[email protected]>
> wrote:****
>
> We are currently bypassing the dynamic rule code and language handlers. We
> need the ability to load rules on the fly instead of pre-loading them. It
> just gives us a lot of flexibility and the benefit of not loading rules we
> may not use.****
>
> ****
>
> Thanks, Darius.****
>
> ****
>
> Steve****
>
> ****
>
> *From:* Darius Jazayeri [mailto:[email protected]]
> *Sent:* Tuesday, August 30, 2011 2:04 PM
> *To:* McKee, Steven Jay
> *Cc:* Dugan, Tammy Marie
> *Subject:* Re: New LogicService method****
>
> ****
>
> Hi steve****
>
> I'm out and about at the moment, but will try to reply on the dev list
> today out tomorrow.****
>
> Isn't there already a workflow so your rule provider can update loaded
> rules though? Or have you ended up bypassing the dynamic rule code and
> language handlers I put in?****
>
> -Darius (by phone)****
>
> On Aug 30, 2011 1:17 PM, "McKee, Steven Jay" <[email protected]> wrote:***
> *
>
> Darius,****
>
> ****
>
> CHICA is very close to finishing the upgrade to OpenMRS 1.7.x, but we’re
> needing an additional method added to the LogicService interface:****
>
> ****
>
> /******
>
> * Loads a rule into memory so it can be used. It will also update the
> rule *metadata* if****
>
> * required.****
>
> * ****
>
> * *@param* token the lookup key ("token") for the rule to be
> loaded.****
>
> * *@param* updateRule Whether or not the rule *metadata* needs to be
> updated once loaded.****
>
> * *@throws* LogicException if an error occurs loading a rule.****
>
> */****
>
> *public* *void* loadRule(String token, boolean updateRule)
> *throws*LogicException;
> ****
>
> ****
>
> CHICA currently has the same method in its DSS module which looks in
> various places to load a rule into memory. We currently have hardcoded
> places in our code to load specific rules before any other rules are
> executed. We want to be able to remove the hardcoded loading of the rules
> so we can be more dynamic about it. ****
>
> ****
>
> Here’s what we are proposing to do:****
>
> 1. Add the new LogicService method.****
>
> 2. Update the Arden parser to create Java calls that execute the
> loadRule method on an inner rule before calling “eval”.****
>
> logicService.loadRule("LocationAttributeLookup", false);****
>
> Result result = context.eval(patient.getPatientId(),
> "LocationAttributeLookup",parameters);****
>
> 3. For the time being the implementation of the loadRule method in
> the logic module will do nothing.****
>
> 4. We will set up an AOP call for the method in our DSS module so we
> can call our own loadRule to get the correct rule into memory.****
>
> 5. The AOP call is a temporary fix until we can eventually get some
> of our DSS code moved into logic in the future. But we’re very close to our
> upgrade deadline at the moment.****
>
> ****
>
> The “updateRule” parameter for the method is used to tell the code whether
> or not the metadata about the rule should be updated. Most of the time in
> normal operating conditions this will be false. The case where we would
> supply true is when are class loading scheduled task is looking for new
> rules. Once it finds a new rule, we want the newest metadata (and
> registration) for it.****
>
> ****
>
> Thanks,****
>
> ****
>
> Steve McKee****
>
> Children’s Health Services Research****
>
> Indiana University School of Medicine****
>
> Phone: 317-278-9660****
>
> Email: [email protected]****
>
> ****
>
> ** **
>
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
