[rules-users] Feature request

Steven Williams stevearoonie at gmail.com
Wed Apr 9 20:52:38 EDT 2008


I also have this requirement. I spoke to Michael Neale about it and he
thought that it shouldn't be too difficult. Michael, I wasn't sure if you
were going to add the feature request or if you want me to do it?

cheers
Steve

On Thu, Apr 10, 2008 at 9:30 AM, Brian Trezise <
Brian.Trezise at intellidata.net> wrote:

>  This is a feature request, or if the feature already exists, a request
> that somebody let me know :)
>
>
>
> I have a set of rules that heavily depend on regular expressions to
> operate.  The regular expression is matched on the LHS of the rule, and then
> passed to another object for additional processing in the RHS of the rule.
> We're looking at a few hundred rules here.  Here's the problem – because of
> needing to use the regexes twice, I have stored them in a separate container
> class as public static final String variables; however what we really want
> to do is to be able to make a modification to either the regex or the rules
> themselves, hot deploy the changes to the rule, and have everything work.
> We specifically do not want to have to try hot-deploying or re-compiling
> classes due to the potential issues that can arise.  As it stands now it's
> looking like we are going to have to endure a pretty heavy maintenance
> burden by changing the rule, hot deploying, then later in the evening
> redeploying the java code and rebooting the server whenever we make a
> change.
>
>
>
> The ideal solution for this problem would be if we could set
> package-scoped variables in the .drl file, outside of the rules.  For
> example, at the top of the drl file, below the import statements, if we
> could write something like the following:
>
>  let String THIS_STRING = "this regular expression";
>
>
>
> and then in the background when the rule classes are generated, have them
> be declared as static final/constant variables.  This way they could be used
> on either side of the rule, but if a change is made the RuleAgent will see
> that and overwrite the old version of the rule package and fact processing
> would be able to continue uninterrupted.
>
>
>
> If anybody has any suggestions on a work around, I would be appreciative.
>
>
>
> Oh, and thanks to everybody for helping me get the RuleAgent to work :)
>
> *___________________________________________________
> Brian Trezise
> Staff Software Engineer
> IntelliData, Inc
> *3173 s. uravan way
> aurora, colorado 80013
> T: 720.524.4864
> brian.trezise at intellidata.net
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>


-- 
Steven Williams

Supervising Consultant

Object Consulting
Office: 8615 4500 Mob: 0439 898 668 Fax: 8615 4501
steven.williams at objectconsulting.com.au
www.objectconsulting.com.au

consulting | development | training | support
our experience makes the difference
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080410/10abb4cc/attachment.html 


More information about the rules-users mailing list