Drools Module for ObjectFilter
Started generalizing ObjectFilter a little bit more by seperating out the rule providers. The style seen previous (manual rule implementation) has been moved into ManualRuleProvider, and I added a DroolsRuleProvider which uses Drools rules for access permissions, as follows:
public void testSlightlyMoreComplexRools() throws Exception
{
Filter filter = Filter.instance();
filter.configure(new DroolsRuleProvider(complex));
filter.setActor(new Actor());
Teacher mr_brown = new Teacher("Mr. Brown");
ClassRoom english = new ClassRoom(mr_brown);
assertEquals(mr_brown, english.getTeacher());
ClassRoom maths = new ClassRoom(new Teacher("Mr. White"));
assertNull(maths.getTeacher());
}
Which looks pretty similar so far. The configure method was added to allow for plugging rule systems in. The complex argument is a java.net.URL pointing to the Drools ruleset.
The rule set for this example looks like:
<rule-set name="DroolsTest"
xmlns="http://drools.org/rules"
xmlns:java="http://drools.org/semantics/java">
<rule name="Mr. Brown is Friendly">
<parameter identifier="actor">
<java:class>org.skife.objectfilter.drools.Actor</java:class>
</parameter>
<parameter identifier="response">
<java:class>org.skife.objectfilter.drools.Response</java:class>
</parameter>
<parameter identifier="subject">
<java:class>org.skife.objectfilter.Teacher</java:class>
</parameter>
<java:condition>
subject.getName().equals("Mr. Brown")
</java:condition>
<java:consequence>
response.setAllowed(true);
</java:consequence>
</rule>
...
stuff removed
...
</rule-set>
The actor and instance being tested are bother asserted into the working memory (new working memory for each test, awkward, but I don't have a better solution in mind right now, any ideas?), rules are fired, and the response is tested to see if the access should be granted.
The response (which provides a way for the rules to tell the Filter what to do, and defaults to "false" to block access) can probably be moved to the ApplicationData bit of Drools, but I haven't done it yet and am getting sleepy =) I am, also, not fully satisfied with the Actor thing I used for this. In order to distinguish between Actor and Subject in the rule I made the actor a specific class -- this is probably how it will need to be done. Another option I am thinking about is to declare mixin tags for Actor or Subject types, but this seems much more intrusive.
I think for now users just need to be aware that there is no convenient way to distinguish between objects asserted as actors and objects asserted as subjects if their types overlap.
The source tarball for the changes has been posted =) Once again, it doesn't include the AspectJ jars as they are big.