You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2007/09/11 04:19:29 UTC

[jira] Created: (DIRSERVER-1059) Interceptor bypass logic is flawed

Interceptor bypass logic is flawed
----------------------------------

                 Key: DIRSERVER-1059
                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1059
             Project: Directory ApacheDS
          Issue Type: Bug
    Affects Versions: 1.5.1
            Reporter: Emmanuel Lecharny
             Fix For: 1.5.2


We currently have many places in the code where we are hard-coding the bypassed interceptor (ie, the interceptors which won't be called).

I think this logic is flawed : as we can add new interceptors, those newly interceptors will be called, or the code where those bypasses are declared should be modified.

Reverting the logic won't help : if we create a list of called interceptors instead of a list of bypassed interceptors, then we will still have to modify the code to add those new interceptors in the chain.

Some other way to handle interceptors should be find to allow users to add new interceptors without any problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (DIRSERVER-1059) Interceptor bypass logic is flawed

Posted by Emmanuel Lecharny <el...@gmail.com>.

Hi David,

On 9/11/07, David Jencks <da...@yahoo.com> 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
-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com