[rules-users] feature request : load config/drl files using full path
Hi, We would need that the file solver-config.xml and the rules files (*.drl) can be loaded using a full path. For the moment, only the classpath is used to load these files. Thanks Michenux ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Feature request
Hi! I am also looking for the feature of being able to define constants in a rules file, that is mentioned in this thread (http://www.mail-archive.com/rules-users@lists.jboss.org/msg05142.html). Is this something that will be considered for a future release? I've been through the JIRA issues but could not find it :( Thanks, /Daniel ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Feature request
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 [EMAIL PROTECTED] ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Feature request
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ rules-users mailing list rules-users@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 [EMAIL PROTECTED] www.objectconsulting.com.au consulting | development | training | support our experience makes the difference ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
