directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [jira] Created: (DIRSERVER-1059) Interceptor bypass logic is flawed
Date Tue, 11 Sep 2007 09:16:47 GMT
Hi David,

On 9/11/07, David Jencks <> wrote:
> I hope you guys don't run off and implement something for this
> without first accepting or rejecting my proposal to eliminate
> InterceptorConfiguration.

Don't worry, I'm just doing some retro-ingeneering atm. I won't
implement anything different without a discussion on the ML. .

> One possibility is to configure the interceptor chains in spring or
> the equivalent.

This is exactly what I was thinking about. But we may also consider
other options.

There are only about 5 or 6 different chains at the
> moment IIUC so a "named chain" that is known to the container and
> injected to the points that need it might work.

So far, I found 10 chains in the server (a few of them like
USER_LOOKUP are declared more than once, though, with different
interceptors in their list)

Then if someone adds
> an interceptor in say the spring configuration they can decide
> exactly which chains it belongs in.  IIRC this is approximately what
> jetspeed does with its interceptor chaings.

That's something we may consider.

> OpenEjb takes a very different approach by not having the ability to
> configure interceptor chains at all: if you want radically different
> behavior you write a new container class.

The problem with interceptors is that they may change the way the
server behave, if you don't chain them in the right order, of if the
added interceptor modify some values. For instance, an interceptor
injecting an new attribute (virtual attributes, for instance) _must_
be added before the schemaService interceptor, which will check that
this added attribute don't conflict with the entry's ObjectClasses.
(it's just an exemple)

There are some integration
> points where most behavior anyone wants can be configured, such as
> the geronimo integration.  IIUC the basic point of view of this
> approach is that there are only a very few points in the chain where
> custonization is approprate, so only those points can be customized:
> the correct behavior of the rest of the container is just hardcoded.

I just reached the same conclusion. Insertion points might be defined.

> Triggers/stored procedures form one such obvious extension point but
> aren't currently powerful enough to be all that is needed.  Possibly
> a declarative referential integrity facility together with triggers
> would be enough.

Thanks for your mail, David. I think this is a very important
discussion we are having, and hopefully Alex will bring some insight.

I would also add that modifying the interceptor chain is not urgent at
all. I would like to release 1.5.2 before that.

Emmanuel L├ęcharny

View raw message