Announcement Announcement Module
No announcement yet.
Hibernate Based ACLs Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Hibernate Based ACLs


    I am currently evaluating Acegi Security for integration into one of our projects. So far, the product looks very promising. The data access layer of this project is based on Hibernate (surprise surprise) and I am currently wrestling with the SimpleAclEntry class.The problem arises on addPermission() and deletePermission() method calls which are inherited from AbstractBasicAclEntry.

    From looking at the source I can see that when these methods are called they reference the validPermissions array in the AbstractBasicAclEntry class. This array is popluated in the full constructor for the AbstractBasicAclEntry class by executing the getValidPermissions() method from a subclass of AbstractBasicAclEntry (in this case SimpleAclEntry). However in the no-arg constructor of AbstractBasicAclEntry, this initialization doesn't occur, so when addPermissions() or deletePermissions() is called on a Hibernated hydrated ACL, a NullPointerException is generated.

    So, the flow is:

    1. Hibernate hydrates an ACL by calling newInstance() (and thus calling the no-arg constructor of my simple extension to SimpleAclEntry.
    2. My no-arg constructor calls super(), and executes the no-arg constructor of AbstractBasicAclEntry, which does nothing.
    3. I then try to call addPermission(int permission) and get an NPE as the validPermissions array hasn't been populated.

    This problem won't just affect Hibernate, but any scheme that constructs any subclass of AbstractBasicAclEntry by calling the default constructor and then a bunch of setters.

    I can see a couple of hacks around the problem, but I must be missing something because this seems too basic a fault to have escaped previous detection. So basically, can anybody please tell me what I am missing?

    Thanks in advance,

  • #2
    AFAIK, most people are using the default DAOs we ship with Acegi Security (which us eSpring JDBC Abstraction layer, not Hibernate). I can see your problem. Would writing a Hibernate UserType provide a solution? Or do you suggest something be changed in the baseline Acegi Security classes?


    • #3
      Hi Ben,

      Maybe this is too simplistic, but I think reworking the constructor ofAbstractBasicAclEntry would do it:

      public AbstractBasicAclEntry()  {
           validPermissions = getValidPermissions();
      I haven't worked through this end-to-end, but can you see any reason why this wouldn't be appropriate?



      • #4
        Committed to CVS.


        • #5
          Could you please provide code of your Hibernate DAOs?

          Tkank you