On Wed, Feb 18, 2009 at 10:06 AM, Emmanuel Lecharny <email@example.com>
>> In order to implement the clear operation, we will have to inject aNot exactly. The logs are stored when we go through the
>> 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.
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.
That mean we have to move the logic into the ChangeLog class. I'm not
We just call revert on ChangeLog
> which we grab from the DirectoryService.
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.
Yeah. This is certainly not perfect atm, but I consider this work 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.
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.
eh eh ;)
>> 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.
Maybe we shoud get rid of it in 3.0 then ... yes, I know, I wanted to
slash it in 1.0 ;)