Hi, What about making ACI parser aware of only Strings instead of attribute types or attribute values? Or moving ACI parser into the core?
On Jan 20, 2008 12:31 PM, 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 > > > -- Ersin Er
