Auditing capabilities on top of IBatis

[Rogelio Baucells <rb...@investran.com>]

Hi,

We have the requirement of implementing auditing at the property level
for our object model. We need to audit all changes to public properties
and persist the auditing information at the time the entity is been
saved. We are evaluating IBatis for such task as the persistence layer
and we have a prototype already working. We had to modify some parts of
IBatis to acomplish this task:

1- We need to modify the way objects are created, for that we created
our own IObjectFactory and returned our own IFactory for the entities we
need to audit. This IFactory creates a dynamic proxy with some extra
functionality needed for the auditing.

We had to modify DomSqlMapBuilder since there is no way to set a custom
IObjectFactory at the time of creating a SqlMapper. I think that it
would be a good enhancement to IBatis having the posibility to specify
your own IObjectFactory and set/get accessors.

2- Another thing we needed was the ability to intercept calls to some
methods in the SqlMap class, the easiest way to accomplish this was
inheriting from the SqlMapper class but the contructor is internal. Also
there is no way to change the way the SqlMapper instance is created
inside DomSqlMapBuilder and in several places in the code classes are
using a reference to the SqlMapper class instead of the ISqlMapper
interface. We finish doing a hack inside our dynamic proxy
implementation of the domain model entities since the change in the
IBatis code was a little more complicated than the one before.

I think the ability to extend/modify IBatis functionality is something
necessary in some cases and it should be built into the main code base.
A functionality similar to the Hibernate interceptors is a good idea or
the possibility to change the default implementation of
accessors/factories and the SqlMapper itself are needed in some cases. I
can work on adding those changes to the main code base if the community
think it is necessary. 

Thanks,

RJB


CONFIDENTIALITY: This email (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this email in error, please notify the sender and delete this email from your system. Thank you.

Re: Auditing capabilities on top of IBatis

[Clinton Begin <cl...@gmail.com>]

Don't inherit from SqlMapper!!!!   It has an interface ISqlMapper that you
can implement with a proxy class of your own.

In general, be very careful extending classes from any framework.  Look for
an interface first.  If one doesn't exist, your still better off favouring
delegation over inheritance by creating your own facade class.

Cheers,
Clinton

On 8/14/06, Rogelio Baucells <rb...@investran.com> wrote:
>
>
> Hi,
>
> We have the requirement of implementing auditing at the property level
> for our object model. We need to audit all changes to public properties
> and persist the auditing information at the time the entity is been
> saved. We are evaluating IBatis for such task as the persistence layer
> and we have a prototype already working. We had to modify some parts of
> IBatis to acomplish this task:
>
> 1- We need to modify the way objects are created, for that we created
> our own IObjectFactory and returned our own IFactory for the entities we
> need to audit. This IFactory creates a dynamic proxy with some extra
> functionality needed for the auditing.
>
> We had to modify DomSqlMapBuilder since there is no way to set a custom
> IObjectFactory at the time of creating a SqlMapper. I think that it
> would be a good enhancement to IBatis having the posibility to specify
> your own IObjectFactory and set/get accessors.
>
> 2- Another thing we needed was the ability to intercept calls to some
> methods in the SqlMap class, the easiest way to accomplish this was
> inheriting from the SqlMapper class but the contructor is internal. Also
> there is no way to change the way the SqlMapper instance is created
> inside DomSqlMapBuilder and in several places in the code classes are
> using a reference to the SqlMapper class instead of the ISqlMapper
> interface. We finish doing a hack inside our dynamic proxy
> implementation of the domain model entities since the change in the
> IBatis code was a little more complicated than the one before.
>
> I think the ability to extend/modify IBatis functionality is something
> necessary in some cases and it should be built into the main code base.
> A functionality similar to the Hibernate interceptors is a good idea or
> the possibility to change the default implementation of
> accessors/factories and the SqlMapper itself are needed in some cases. I
> can work on adding those changes to the main code base if the community
> think it is necessary.
>
> Thanks,
>
> RJB
>
>
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error, please
> notify the sender and delete this email from your system. Thank you.
>

Re: Auditing capabilities on top of IBatis

[Gilles Bayon <ib...@gmail.com>]

On 8/14/06, Rogelio Baucells <rb...@investran.com> wrote:
>
>
> Hi,
>
> We have the requirement of implementing auditing at the property level
> for our object model. We need to audit all changes to public properties
> and persist the auditing information at the time the entity is been
> saved. We are evaluating IBatis for such task as the persistence layer
> and we have a prototype already working. We had to modify some parts of
> IBatis to acomplish this task:
>
> 1- We need to modify the way objects are created, for that we created
> our own IObjectFactory and returned our own IFactory for the entities we
> need to audit. This IFactory creates a dynamic proxy with some extra
> functionality needed for the auditing.
>
> We had to modify DomSqlMapBuilder since there is no way to set a custom
> IObjectFactory at the time of creating a SqlMapper. I think that it
> would be a good enhancement to IBatis having the posibility to specify
> your own IObjectFactory and set/get accessors.


Look at

/// <summary>
        /// Allow to set a custom object factory, see <see
cref="IObjectFactory"/>
        /// before configuration
        /// </summary>
        public IObjectFactory ObjectFactory
        {
            set { _objectFactory = value; }
in DomSqlMapBuilder
        }


2- Another thing we needed was the ability to intercept calls to some
> methods in the SqlMap class, the easiest way to accomplish this was
> inheriting from the SqlMapper class but the contructor is internal. Also
> there is no way to change the way the SqlMapper instance is created
> inside DomSqlMapBuilder and in several places in the code classes are
> using a reference to the SqlMapper class instead of the ISqlMapper
> interface. We finish doing a hack inside our dynamic proxy
> implementation of the domain model entities since the change in the
> IBatis code was a little more complicated than the one before.
>
> I think the ability to extend/modify IBatis functionality is something
> necessary in some cases and it should be built into the main code base.
> A functionality similar to the Hibernate interceptors is a good idea or
> the possibility to change the default implementation of
> accessors/factories and the SqlMapper itself are needed in some cases. I
> can work on adding those changes to the main code base if the community
> think it is necessary.
>
> Thanks,
>
> RJB
>
>
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error, please
> notify the sender and delete this email from your system. Thank you.
>



-- 
Cheers,
Gilles

<a href="http://www.amazon.com/gp/registry/6JCP7AORB0L">Wish List</a>