directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [ApacheDS] Cost of interceptors
Date Tue, 29 May 2007 06:22:50 GMT
On 5/29/07, Emmanuel Lecharny <> wrote:
> Trustin Lee a écrit :
> > Hi Ersin,
> >
> > On 5/28/07, Ersin Er <> wrote:
> >
> >> Well, I am talking about an interceptor chain in a chain.
> >>
> >> Int1 -> Int2 -> Int3(Int3.1 -> Int3.2 -> Int3.3) -> Int4 - >
> >>
> >> If Int3 is enabled all Int3.x will be executed. If Int3 is disabled,
> >> the executed will just be forwarded to Int4, not Int3.1. This is
> >> because the Kerberos service can be enabled or disabled at all. BTW,
> >> if Kerberos service is enabled and it's desired to disable a
> >> subservice of it, it's still possible. Int3.x can only know about
> >> other Int3.x if needed. Int3 is a blackbox, it is just a regular
> >> interceptor to the outer world. It has a registration mechanism, as
> >> just Interceptors have, which can again register Interceptor. Well, I
> >> think Int3 implements two interfaces: InterceptorChain and
> >> Interceptor.
> >
> >
> > We need to ask ourselves before providing such a composite
> > interceptor; Is each element of the composite interceptor useful
> > independently?  If not, why do we need to implement each sub-logic as
> > an interceptor?  Can't we just implement it as a POJO and use it as a
> > utility from an interceptor that assembles the sub logic?  Adding a
> > composite interceptor feature will cause complexity to the interceptor
> > architecture so we need to be careful.  Of course, adding it is not a
> > problem at all once we have a concrete use case.
> >
> > Trustin
> Hi guys,
> I must say that Ersin idea is quite natural, but that Trustin objections
> are also acceptable. What I wanted to add is that we have issues with
> the current pattern and I would like to start thinking about solutions
> to those issues. Here they are :
> - the Interceptors are supposely dynamic, but even if the addBefore and
> addAfter methods are synchronized, the code itself is not threadsafe
> (it's ok to protect method, but as we don't protect access to the get()
> metho to, this is useless. It would be better to protect the hashmap.)
> - debugging an interceptor chain is a nightmare : as we don't know
> explicitely which is the next interceptor, we have to step to a *lot* of
> classes, to end with a stack which has sometime more than one hundred
> method calls...
> - btw, each method which is not void *must* logs something, like
> "entering this interceptor" and "returning from this interceptor". It
> would have helped me a lot, avoiding never ending debug sessions... Log
> log log !
> - as each method in an interceptor should know which is the next
> interceptor to call for the same method, this leads to some mi of
> concept : we are dealing with a chain of global interceptors into which
> each motho has its own path. At this point I just wonder if it would not
> be better to define a add() interceptorChain, delete() interceptorChain,
> search() interceptorChain etc.
> - I'm not sure that a method should know which interceptor it must call.
> I think it would be better to see this interceptor chain as a state
> machine, with calculated transitions. Adopting this vision will allow a
> lighter system, where pre and post conditions would be run partly on the
> engine (the transition selector) and partly in the next state. In fact,
> we will have two kinds of pre and post conditions : selectors pre/post
> productions, and applicatives pre/post treatment.
> Ok, I want to be honest, I'm not sure I see a better solution than the
> one we actually have, which works pretty well, but I *feel* that it
> could be done better. May be I'm totally wrong, may be is just because
> I'm an old fart and pretty much biased toward state machines - old
> school computer science :) -, I don't know. I just wanted to open a
> thread on this subject, but, please, *no flame* ! I don't think there is
> an ultimate solution, I would just like to see if we have explored other
> paths...

Why not building a prototype?

> Emmanuel
> PS : this is all but urgent. Not a big deal if we decide to refactor -
> or not - this pattern in 6 months or in 2 years. As this is the heart of
> ApacheDS (which has many hearts;), it's better to think twice than doing
> bad...

View raw message