-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kiran Ayyagari Sent: Wednesday, November 10, 2010 2:58 AM To: Apache Directory Developers List Subject: Re: Does trunk have a method to load old style ldif schema files?
On Wed, Nov 10, 2010 at 9:09 AM, Hammond, Steven <[email protected]> wrote: > 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. > hmm, this is strange, it *will* accept the ldif file you have given. Can you elaborate what do you mean by 'that expected new format' is? ** The @ApplyLdifFiles has no effect until I call DSAnnotationProcessor.applyLdifs, and the fact that function takes an org.junit.runner.Description made me think it is more for test only purposes. Also, since my project has moved to Junit 4, the Description that I can make, does not have a getAnnotation method: java.lang.NoSuchMethodError: org.junit.runner.Description.getAnnotation(Ljava/lang/Class;)Ljava/lang/annotation/Annotation; at org.apache.directory.server.core.factory.DSAnnotationProcessor.applyLdifs(DSAnnotationProcessor.java:316) I also tried DSAnnotationProcessor.injectLdifFiles, had trouble getting around the clazz parameter, then once I faked that, the injectEntry failed on attribute types saying my Schema (commObject) was not enabled. But I have not changed these ldif files from my 1.5.3 running system. > 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. > right, but I would prefer injecting them manually rather than through bundled jar(very likely you might get the duplicate resource exception due to the presence of cn=schema in the new jar also) > 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()); this works too ** 2.0 does not have an ApacheDS class that I can new, and I do not see that setLdifDirectory has moved to another class that I can use. Have I missed it? > > -----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 > -- Kiran Ayyagari
