directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hammond, Steven" <Steven.Hamm...@Polycom.com>
Subject RE: Does trunk have a method to load old style ldif schema files?
Date Wed, 10 Nov 2010 15:48:41 GMT


-----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
<Steven.Hammond@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
> <Steven.Hammond@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

Mime
View raw message