Wierd iteration with drools and identity

[mrauls.mrauls.akimeka.com]

I'm curious if anyone can explain what is going on here. I have an application that is using a simple rule to show/hide a piece of the page based on a user's roles. As I was trying to get the rule to work, I added some debugging code to my custom identity class (MyIdentity). So now, everything appears to be working correctly, except that a single decision on a single page view seems to be making a large amount of method calls and firing of the same rule. Is this normal?

Applicable part of security.drl:

rule RestrictBloodEntry
  no-loop true
  activation-group "permissions"
when
  check: PermissionCheck(target == "blood.entry", granted == false)
  Role(name == "phi") and 
  Role(name == "blood-entry") 
then
      System.out.println("The blood.entry PermissionCheck's properties are: " +
        "name=" + check.getName() + ", action=" + check.getAction());

  check.grant();
end

The applicable part of the view:

  
...
    <rich:panel rendered="#{s:hasPermission('blood.entry', 'create')}">
        ...

    </rich:panel>
...

The debugging statement. Each time I hit the page, 8 repetitions of this pattern occur:

17:13:57,974 INFO  [MyIdentity] MyIdentity.hasRole()com.company.project.session.MyIdentity@2413d9
17:13:57,974 INFO  [MyIdentity] MyIdentity.hasRole()com.company.project.session.MyIdentity@2413d9
17:13:57,974 INFO  [MyIdentity] MyIdentity.hasRole()com.company.project.session.MyIdentity@2413d9
17:13:57,974 INFO  [MyIdentity] MyIdentity.hasRole()com.company.project.session.MyIdentity@2413d9
17:13:57,990 INFO  [STDOUT] The blood.entry PermissionCheck's properties are: name=blood.entry, action=create

[mrauls.mrauls.akimeka.com]

From MyIdentity:

     
        public boolean hasRole(String role){
          log.info("MyIdentity.hasRole()"+this);
          return super.hasRole(role);
     }

[joblini]

Hi Matt,

For what its worth, I think this is a JSF issue, I have noticed a large number of calls to getter methods where one would think that one call should suffice. 

If my memory is correct there was a discussion a while ago on the Seam developer's list, the idea was that Seam could improve performance by caching such calls.