Hi,
another problem I'm currently facing, and can't simply fix : when a
schema is disabled, it must still be loaded into the server as we should
allow users to enable it using a simple Ldap Modify request (changing
its m-disabled AT). Another aspect of the story is that if we want to
enable a schema globally, we must have a list of all its SchemaObjects
available, and this structure is build on startup.
Now, the big problem is that when loading the schema on startup, we have
to check that the AT, MR, OC... are correct (ie, all the OC's
attributeType are present in the server, for instance). We are using the
registries for that purpose, but sadly, if an element is disabled, it is
not present inits registry, and the next step fails.
An option would be not to check the SchemaObject structure when loading
them (either at startup or when the element is injected into the
server), but to do it when enabling the element (or disabling, as it may
impact some other elements). We do that on Studio, checking the whole
loaded schema after every operation : costly.
Using the 'isEnabled' flag present in each SchemaObject would be
overkilling, assuming that the registries contain all the SchemaObject,
enabled or not : it will have to be done for every search request, in
the SchemaInterceptor. Simply unaceptable.
An easier possible option would probably to have to sets of registries :
one with the enabled SchemaObject and another one with the disabled
SchemaObject. That would have an impact on the way the schema is
handled, as we will have to update either one or the other structure,
and we also will have to check on both registries when checking the
SchemaObjects. That's a lot of code too.
We can also use a shadow registries, containing all the schemaObject,
but only used by the schema subsystem. A bit of duplication...
any thought before I make a choice ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
