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 Mon, 22 Nov 2010 20:47:19 GMT
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
<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

Mime
View raw message