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 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. Alex On Jan 20, 2008 5:31 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> 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 > www.iktek.com > directory.apache.org > > >
