[ http://issues.apache.org/jira/browse/DIREVE-228?page=comments#action_12319354 ]
Kirill Kovalenko commented on DIREVE-228: ----------------------------------------- > I faced problems due to this one with Softerra LDAP Browser 2.6, when I was > trying to find/fix this bug > This browser provides a schema cache, which is even not refreshed after a > restart, if the server fails to give the > attribute Kirill mentioned. I had to delete the cache on disk in order verify > that my Fix for DIREVE-227 works > with this client. Just FYI: LDAP Browser supports manual schema reload. (Profiles properties->LDAP Settings->Advanced->LDAP Schema->Reload schema). The application restart required. > Schema container issue. > ----------------------- > > Key: DIREVE-228 > URL: http://issues.apache.org/jira/browse/DIREVE-228 > Project: Directory Server > Type: Bug > Components: schema > Versions: 0.9.2 > Reporter: Kirill Kovalenko > Assignee: Alex Karasulu > > 1) It looks like that recently implemented [1],[2] RFC3673 support (all > operational attributes) doesn't work for the schema entry. Attributes > objectClasses, matchingRules, attributeTypes are not returned when '+' > special attribute is used. > 2) Schema container doesn't seem to provide modifyTimestamp attribute. > Absence of modifyTimestamp attribute makes it impossible for client to track > schema modifications easily. > Here is what RFC2251 [3] says about it (section 3.2.2). > Servers SHOULD provide the attributes createTimestamp and > modifyTimestamp in subschema entries, in order to allow clients to > maintain their caches of schema information. > [1] http://issues.apache.org/jira/browse/DIREVE-210 > [2] http://issues.apache.org/jira/browse/DIREVE-219 > [3] http://rfc.net/rfc2251.html#s3.2.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
