directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: ChangeLog + revert, broken , take 2
Date Wed, 18 Feb 2009 15:50:00 GMT
On Wed, Feb 18, 2009 at 10:06 AM, Emmanuel Lecharny <>wrote:

> >> In order to implement the clear operation, we will have to inject a
> >> new field into each operationContext : the bypassed interceptors.
> >
> > We should not need to do this. We expose access to the ChangeLog
> (interface)
> > from the DirectoryService itself. This allows us to manage the changelog
> out
> > of band (of ldap operations which go through the interceptor chain).
>  This
> > is how reverts work today for example.
> Not exactly. The logs are stored when we go through the
> ChangeLogInterceptor. That mean we compute the reverted operation,
> copy the forward operation and call the log operation when doing a
> revert.

Right this happens in the interceptor chain in band obviously to log the
changes that are occurring.

> We just call revert on ChangeLog
> > which we grab from the DirectoryService.
> That mean we have to move the logic into the ChangeLog class. I'm not
> against this idea, however, we have to move almost all the codefrom
> the interceptor to the ChangeLog class. Not a lot of work though ...

Sorry not understanding why we have to do this.

> >> As
> >> we don't want he changeLog to be executed when reverting operations,
> >> we have to bypass it.
> >
> > Hmmm we want to lock out any changes which may be taking place while a
> > revert is in progress.  Implementing this is a lot more involved and
> > something we need to talk more about.
> Yeah. This is certainly not perfect atm, but I consider this work as
> the second iteration from a prototype toward a stronger systemn which
> will be used for the DRS, so most certainly not a waste of time.

Not a waste of time. However we will be using structures not designed for
this purpose, convoluting the code base, and making it more difficult to
refactor things properly when even more will be stacked on top of this
interceptor structure with bypasses as it sits today.

> >
> >>
> >> We also may want to bypass some other
> >> interceptors , like the authz or authn (if we have successfully
> >> modified something, then we will successfully do the revert).
> >>
> >> Adding a Collection of bypassed interceptors into the operationContext
> >> will allow such a mechanism to work. It should not break the current
> >> code base, as the PartitionNexusProxy handle such bypasses.
> >
> > The bypass mechanism was never created for handling these kinds of
> problems.
> > In fact the bypass mechanism is a very dangerous and ugly work around to
> > flaws in the interceptor chain design.
> eh eh ;)
> Maybe we shoud get rid of it in 3.0 then ... yes, I know, I wanted to
> slash it in 1.0 ;)

Yes I would like to clean it up or find a better data structure to suite our
purposes.  The intent was to have something to decouple these concerns
(aspects) which are handled by different interceptors.  However this
certainly is not the case now as some interceptors need to be aware of
others and placement order is an issue (don't know if order is solvable).
Anyways this is best put into a different ML thread.

Right now we should provide simple CRUD operations for managing the CL
without getting to complicated about it. I think we're over thinking things.


View raw message