A while back there was some discussion about just how much container
functionality apacheds needs to duplicate for spring, and IIUC there
was general agreement that [Mutable]InterceptorConfiguration could be
replaced by just letting the container create the interceptors directly.
I started looking at this issue this morning and think it would be
pretty easy to fix so I'm wondering if there's any chance it could
get into 1.5.1.
I also see what looks to me like double-checked-locking problems with
InterceptorChain setting up the chain of Entry objects. IIUC there
are a bunch of methods to insert,remove, etc interceptors in the
running server but the actual code that traverses the interceptor
chain is not at all synchronized. This is a double-checked-locking
scenario and can lead to the live interceptor chain using
incompletely initialized interceptor objects. The usual fix nowadays
for such problems is to make the variables pointing to the possibly
incompletely initialized objects volatile. IIUC this would be the
InterceptorChain.Entry prevEntry and nextEntry fields.
AFAICT the runtime change-the-chain methods are not called in the
apacheds code base at the moment, so I think an acceptable
alternative would be to remove those methods and rely on no one
starting to use the server until it's fully initialized. This would
involve removing the InterceptorChain addFirst, addLast, addBefore,
addAfter methods.
OK... back to the how-much-extra-wrapping question.
I haven't started to code yet but I think the best solution for now
will be to:
- In each interceptor class that actually uses an interceptor
configuration, replace that with individual attributes (I think only
the replication interceptor has any attributes at the moment)
- remove the InterceptorConfiguration cfg argument from Interceptor.init
At this point we won't need InterceptorConfiguration any more, the
container (spring) can create the interceptors itself, and
InterceptorChain will get a list of interceptors it needs to
initialize rather than a list of InterceptorConfigurations.
thanks
david jencks
