On Oct 4, 2007, at 10:38 AM, Matt Peterson wrote:
Alex,
I'm not sure that including two sets of operational parameters for
calls to the partition is the right answer. Doing this would allow
partitions to be written that could not benefit from optimizations
made by interceptors. I like the interceptor paradigm because it
encourages modularity and code reuse. I think that it would be wise
to "encourage" partition authors to use interceptors appropriately
and not embed into the partition what should be in an interceptor.
However, it would also be wise to allow users the option of not
using certain interceptors with a particular partition. In other
words, we need per-partition interceptor configuration. I'm fairly
focused on my current project, but I think it would be generally
useful to make the interceptor configurations a property of the
partition configuration (in server.xml). This way users can select
the set of interceptors that they'd like to use with a given
partition. Situations where interceptor functionality is required
by a partition (such as normalization) could easily be detected in
individual partition initialization code and result in the
appropriate (graceful) warning or failure.
I think its clear that there are problems with the current "skip
list" approach when people add custom interceptors that perhaps
should only be used in some circumstances. I've wondered if this
problem could be solved by explicitly configuring the interceptor
lists for each purpose in the spring xml rather than any of
hardcoding the skips (current approach), hardcoding the
"applies" (opposite and perhaps even worse approach) or building a
logic engine to decide (I think this has in fact been tried by some
projects). I think jetspeed uses an approach similar to "configure
lots of lists explicitly".
If this idea of configuring lots of interceptor lists in server.xml
worked out it might be pretty easy for these to be specified per
partition as well.
Not sure, but I think what I've described above would work for
embedded implementations too...
--
Matt
P.S. - I'm still looking for an elegant way to implement
interceptor bypass in the current 1.x codebase. Still haven't
found one that wouldn't also change the Interceptor interface
(resulting in a cascade of changes). Looking at a few more ideas
before I give up.
Personally I think it's slightly easier to understand what is going
on in the bigbang branch and if you pursue something like the
"explicit lists" approach we could actually commit it without
rewriting if you work against that moving target.
thanks
david jencks
On 10/4/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
Also at some point we may include two sets of operation
parameters. One set is the
original set of parameters for the operation without any
alterations taking place such as
those with normalization or other optimizations. Another set will
be the same parameters
tweaked by the system which should be applied by partitions.
These are considerations for our bigbang branch which is
refactoring the 1.5 line for a
2.0 release. I think by providing the original request objects in
the operation context as
well as the modified versions of them your problem will probably go
away.
Still though feel welcome to follow this activity to make sure your
needs are met as
we change the server's architecture. Any recommendation or
involvement would be
highly appreciated.
Alex
On 10/4/07, Matt Peterson <[EMAIL PROTECTED] > wrote:
Ok. I will. Thanks.
On 10/3/07, Alex Karasulu <[EMAIL PROTECTED] > wrote:
Yes I understand. If you would like to implement this bypass
capability based on the target DN then feel
free to submit a patch.
Thanks,
Alex
On 10/3/07, Matt Peterson <[EMAIL PROTECTED] > wrote:
Greetings,
I'm trying to write a custom partition that will be used as context
partition, but I'd like to continue to use the Btree/Jdbm partition
implementation for the system configuration partition.
With a little trial and error (mostly errors), I've found out that
several methods in the JdbmPartition (used by the system
configuration partition partition) will not work unless preceeded
by a corresponding "fix-ups" provided by the interceptors. For
example, calls to to the methods in
org.apache.directory.server.core.normalization.NormalizationService
must be made, or BindDNs can not be resolved. Unfortunately,
MyCustomPartition, doesn't like the way that LdapDNs, attributes
and filters are normalized by
org.apache.directory.server.core.normalization.NormalizationService.
In other words, there appears to be more than at least one
situation where a correlation between interceptors and partitions
is necessary, but what we have (at least in Apache DS 1.0.x) is a
design where all interceptors in the chain are called regardles of
the partition that will eventually be invoked. To configure per-
partition interception.
Perhaps what I'm looking for is a way that I can insert my
interceptor first in the chain and then optionally skip other
interceptors if I encounter a DN or base that I know will invoke my
partition? According to documentation for ApacheDS 1.0.x (http://
directory.apache.org/apacheds/1.0/interceptors.html) the Nexus is
called by a "special interceptor" at the end of the chain.
Therefore, it seems very difficult to skip interceptors in the
chain without also elimintating the call to PartitionNexus ...
I suppose my real question is why ApacheDS wasn't designed so that
interceptors could (optionally) be configured for association only
with a certain suffix or partition. This would allow the
configuration flexibility that I would need -- to use both the
JdbmPartition and my own customPartition without having to undo all
of the normalization, schema, referral (,etc) stuff in my own
customPartition that I didn't want done in the first place...
Does this make any sense?
--
Matt
