You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Hammond, Steven" <St...@Polycom.com> on 2010/11/09 18:00:35 UTC
Does trunk have a method to load old style ldif schema files?
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?
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
RE: Does trunk have a method to load old style ldif schema files?
Posted by "Hammond, Steven" <St...@Polycom.com>.
-----Original Message-----
From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] 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
<St...@polycom.com> 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: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] 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
> <St...@polycom.com> 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
Re: Does trunk have a method to load old style ldif schema files?
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Nov 10, 2010 at 9:09 AM, Hammond, Steven
<St...@polycom.com> 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?
> 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
>
> -----Original Message-----
> From: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] 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
> <St...@polycom.com> 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
RE: Does trunk have a method to load old style ldif schema files?
Posted by "Hammond, Steven" <St...@Polycom.com>.
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: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] 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
<St...@polycom.com> 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
RE: Does trunk have a method to load old style ldif schema files?
Posted by "Hammond, Steven" <St...@Polycom.com>.
Just for an update, I have not tried the importing a schema thru UI, then saving the new file definition, because this would be a bad ongoing practice. But it seems I have exhausted all other paths.
Should I open a Jira ticket that we can no longer import Schemas using LDIFS?
I tried ApplyLdifs, but that takes a description parameter that is part of Junit, not real good for production code, and the Description I can get out of Junit does not have the getAnnotation method on it.
I tried DSAnnotationProcessor.injectLdifFiles directly, but it could never open the file names i gave it.
I tried writing my own injectLdifFiles method, but always got an error when trying to add attributes to an objectclass that I had just added, saying that this objectClass is not yet loaded.
I tried making my own implementation of AbstractSchemaLoader, but that pukes saying that all schemas must have a valid creatorsName attribute.
Can we have something as simple as ApacheDS.setLdifDirectory(File) that loads all ldifs in a directory back?
-----Original Message-----
From: Hammond, Steven
Sent: Tuesday, November 09, 2010 8:40 PM
To: 'Apache Directory Developers List'
Subject: RE: Does trunk have a method to load old style ldif schema files?
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: ayyagarikiran@gmail.com [mailto:ayyagarikiran@gmail.com] 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
<St...@polycom.com> 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
Re: Does trunk have a method to load old style ldif schema files?
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Nov 9, 2010 at 10:30 PM, Hammond, Steven
<St...@polycom.com> 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