Our system is probably non standard. I do not have access to connect to the system and import the ldif. I need to do it programmatically during startup. So I have the @CreateDS and I tried @ApplyLdifFiles, but that expected the new format.
If I get my dev system running, then import the ldifs, using directory studio I assume, would that create the files with the new directory structure, then I could jar those up and ship with the product and they would be loaded at startup, right? I will try it in the morning. The old method was what I was using in 1.5.3, I don't know if other customers you have were utilizing it to extend their schema also, but I assume so. ads = new ApacheDS(directoryService, ldapServer, null); ads.setLdifDirectory(new File(Environment.getResourcePaths().getLDIFDir()).getAbsoluteFile()); -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kiran Ayyagari Sent: Tuesday, November 09, 2010 8:01 PM To: Apache Directory Developers List Subject: Re: Does trunk have a method to load old style ldif schema files? On Tue, Nov 9, 2010 at 10:30 PM, Hammond, Steven <[email protected]> wrote: > I have our system almost all up and running on trunk so that I can be ready > when 2.0 comes out. I am stuck on trying to add my attribute types. They > are in the old style ldif files, it seems that the new schemas are in a new > subdirectory format. Is there a way to convert or a preferred way to extend > the existing schema? how about directly importing the ldif files you have? (they will eventually be stored in the new directory structure under the schema partition) > > > > I have 13 files (11 of them are H.350, 2 custom) > > > > One of the custom looks like: > > > > # Generated by Apache Directory Studio on December 10, 2009 12:23:39 PM > > > > # SCHEMA "POLYCOMCMA" > > dn: cn=PolycomCMA, ou=schema > > objectclass: metaSchema > > objectclass: top > > cn: PolycomCMA > > > > dn: ou=attributeTypes, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: attributetypes > > > > dn: m-oid=1.3.6.1.4.13885.15.1, ou=attributeTypes, cn=PolycomCMA, ou=schema > > objectclass: metaAttributeType > > objectclass: metaTop > > objectclass: top > > m-oid: 1.3.6.1.4.13885.15.1 > > m-name: PlcmUserType > > m-description: Type of User, 0 is Normal, 1 is GuestBook > > m-equality: integerMatch > > m-ordering: integerOrderingMatch > > m-syntax: 1.3.6.1.4.1.1466.115.121.1.27 > > m-length: 0 > > m-singleValue: TRUE > > > > dn: ou=comparators, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: comparators > > > > dn: ou=ditContentRules, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: ditcontentrules > > > > dn: ou=ditStructureRules, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: ditstructurerules > > > > dn: ou=matchingRules, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: matchingrules > > > > dn: ou=matchingRuleUse, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: matchingruleuse > > > > dn: ou=nameForms, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: nameforms > > > > dn: ou=normalizers, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: normalizers > > > > dn: ou=objectClasses, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: objectClasses > > > > dn: ou=syntaxCheckers, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: syntaxcheckers > > > > dn: ou=syntaxes, cn=PolycomCMA, ou=schema > > objectclass: organizationalUnit > > objectclass: top > > ou: syntaxes > > -- Kiran Ayyagari
