4 Replies Latest reply on Feb 14, 2012 8:00 AM by Adam Warski

    Why are so many classes/methods "final" or "private"?

    brettreyno Newbie

      Hello everyone,

       

      My company is trying to start using Envers to add auditing to our product, however we're having a number of issues integrating it. I've isolated the cause of several of the problems, and I was hoping to be able to fix them without modifying the Envers code too much, however many of the classes I'm looking to extend are marked as "final." Some of these include AuditMetadataGenerator, CollectionMetadataGenerator, and a few others. In other cases, the methods I'm hoping to override or fields I need to access are marked as private, making those changes difficult.

       

      Is there a particular reason why these (and other) classes, fields, and methods are made inaccessible to other classes, even subclasses? It makes it difficult to set up Envers, particularly when Envers does not appear to support several elements the rest of Hibernate supports (we're using 3.6.9, btw).

       

      Thanks!

        • 1. Re: Why are so many classes/methods "final" or "private"?
          Adam Warski Master

          Hmm probably an experiment on my side with some coding style. Feel free to submit patches which remove those and make the code more easy to extend

           

          What elements does not Envers support?

           

          Adam

          • 2. Re: Why are so many classes/methods "final" or "private"?
            brettreyno Newbie

            Thanks, that's good to know. :-)

             

            The two main issues I've encountered so far are:

            • Envers doesn't appear to support Hibernate's CustomCollectionType; CollectionMetadataGenerator's addMapper() method has a series of instanceof checks to determine what sort of collection a property is, but if it's a CustomCollectionType, it falls through to the line throwing the UnsupportedTypeException.
            • Envers also doesn't appear to work with the Interceptors to create objects when you attempt to recover an old version of an audited object. Our application maps Interfaces rather than Classes, using a custom Interceptor to call a Factory method rather than an object's constructor, but Envers just assumes a default constructor exists. Since Interfaces don't have constructors, it crashes trying to rebuild these objects.

            There's another issue we've found, but I haven't yet determined if it's a problem with how we're doing things or something missing in Envers, but either way we'll get it sorted out. Thanks!

             

            Edit: Again, this is all as of Hibernate 3.6.9 - has any of this been addressed in 4 yet?

            • 3. Re: Why are so many classes/methods "final" or "private"?
              brettreyno Newbie

              To add on to my first bullet there, it seems as though it doesn't work with ArrayType or IdentifierBagType either, and both OrderedSetType and OrderedMapType are only supported through their superclasses (SetType and MapType).

               

              I think I've worked out a way to resolve these issues, however it'll probably be some time until a patch is submitted due to my company's code review procedures with regards to FOSS.

              • 4. Re: Why are so many classes/methods "final" or "private"?
                Adam Warski Master

                Nope, none of this is addressed in 4. As I see hopes for the Interceptor case, it probably will be worse with custom collections - possible a fix would require to provide a mechanism for providing a custom-audit-collection implementation. But maybe not

                 

                I hope you'll manage to get through your company's FOSS policy

                 

                Adam