[
https://issues.apache.org/jira/browse/DIRSERVER-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Karasulu closed DIRSERVER-883.
-----------------------------------
Resolution: Invalid
The present design was conceived to make sure (at all costs) to remove the
authoritative copy problem of schema files. Your solution re-introduces that
but in the form of an LDIF file. If users don't have a clue and they modify
the LDIF file thinking they will modify the schema there then we have a
problem. Furthermore if they modify the schema via the protocol then what is
in the DIT is different from the LDIF file. Again we have the same
authoritative copy problem. The present solution although a bit involved
removes this issue entirely.
> Improve the way Schema are loaded
> ---------------------------------
>
> Key: DIRSERVER-883
> URL: https://issues.apache.org/jira/browse/DIRSERVER-883
> Project: Directory ApacheDS
> Issue Type: Improvement
> Affects Versions: 1.5.0
> Reporter: Emmanuel Lecharny
> Fix For: 1.5.1
>
>
> As far as I understand the way schema are loaded into 1.5.0 version of the
> server, we can improve it to be more versatile.
> We have 5 kind of elements which are part of the schema repository :
> 1) mandatory elements, like ObjectClass, Top, Name, Desc, any objects without
> which the server can't load a schema.
> 2) meta-schema elements, which are used to declare a new schema
> 3) core schemas, like Core, System, ApacheDs, which are loaded first
> 4) Extension schema, like Samba, Nis, etc.
> 5) User defined schema
> Right now, we have a bootstrap sequence which is quite complicated :
> 1) the server is started, and declare the mandatory elements
> 2) The metaSchema is loaded, with the core schema, from some generated java
> classes (the schema are only used when compiling the server, to generate
> those java classes)
> 3) The extended classes are loaded from some generated partition (there is a
> file named DBFILES which contains the list of all the backend files, files
> which will be created when compiling the server from the generated java
> classes)
> 4) the server is available.
> IMO, we can do the bootsrap differently :
> 1) server startup : we load the mandatory elements
> 2-a) if this is the first time the server is started, load the Ldif files
> representing the MetaSchema, and all the other Ldif files, so that the
> cn=schema partition is fed with the base and extended schema
> 2-b) if the schema is already loaded, do nothing except if we have one file
> which date is younger than the last modification date in the cn=schema
> partition.
> The list of schema ldif files will be stored into the server.xml file,
> assuming that the order must be corect (we must load core.schema before any
> other shcema, etc.)
> This process will be much simpler and easier to modify than the first one,
> and we will be able to remove some projects and plugins, like the
> apacheds-bootsrap-schema and apacheds-schema-extra projects.
> Not sure I'm totally right...
> Wdyt ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
