directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ServerEntry] ProtectedItems compatibility...
Date Sun, 20 Jan 2008 16:46:50 GMT
Hi Emmanuel,

I sympathize with you.  This ACDF engine is a mess besides having this
problem.  Before we can evaluate our options I think we have to ask
ourselves if this code is being used by the Studio folks.  If it is not I
think the best route here is to design the parser so it does use
ServerAttributes but and ServerValues.  The parser must change and the
wrapper which invokes the parser needs to take some rudimentary arguments
that allow it to access registries in the server on demand.  Perhaps it
needs a handle on the DirectoryService from which it can access the

It's very important that these registries be accessed when needed instead of
holding a reference to them since the registries may be swapped at some
point when schema changes occur.  Right not that's not the case but we need
to keep this in mind.  So the best option here is to move the ACIItem parser
into the core and change it to take a DirectoryService object in the
parser's wrapper while changing the parser to use this object to get ahold
of the registries to access attributes and create respective values.

I don't see any other reasonable options besides relying on
ServerAttribute->Attribute transformation which will cost too much
especially when evaluating ACIItems on search.


On Jan 20, 2008 5:31 AM, Emmanuel Lecharny <> wrote:

> Hi,
> I'm stuck in some chicken and egg problem again... The ACDF engine uses
> collections of elements to allow or forbid access to those elements. For
> instance, we can forbid access to some specific values of a specific
> attribute, and we use a ProtectedItem.AttributeValue element for that
> purpose.
> As you can see, we have a collection of valued Attributes stored
> somewhere, and this collection has been created by the ACIItem parser.
> (Basically, you create a list of protected values, stores it in the
> server, the parser is kicked on while adding this data into the server,
> the collections are fed, and now the server is able to protect the data
> by filtering them using the newly updated collections).
> The problem is that the ACIIterm parser is defined in shared-ldap, where
> we have no knowledge about the registry. If we want to store those
> AttributeValue elements, we have to create Attribute, and we have to use
> the JNDI Attribute for that, because we can't have access to the
> AttributeType registry in shared-ldap. But every element in the server
> aren't anymore JNDI Attribute, so we are stuck in the mud here... Either
> we translate the ServerAttribute to JNDI Attribute, or we modify the
> parser to generate ServerAttribute instances. (which mean : the ACIItem
> parser is moved from JNDI to some other place).
> Both choices are wrong ... So what can we do ?
> Any idea ?
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message