On Wed, Feb 18, 2009 at 10:06 AM, Emmanuel Lecharny <elecharny@apache.org> 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

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.