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 registries.
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.
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
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 ?