On Fri, Aug 6, 2010 at 1:57 PM, Emmanuel Lecharny <[email protected]> wrote: > On 8/6/10 10:15 AM, Kiran Ayyagari wrote: >> >>> IMO, this is barely acceptable for API 0.2, but has to be fixed for 0.3. >>> There is no reason to extract to disk when all the ldifs are available in >>> a >>> jar, as it's just a matter of loading them in memory. >>> >>> It should be a 2 hours work to get the code read the jar and load the >>> schema >>> in memory... >> >> it is already possible to do this using JarLdifSchemaLoader , but note >> that this will always >> contain the bundled default schemas only. A user can only add custom >> schema if the >> schema directory is present on disk. > > Ah, so we are golden. > > Is there a place where this is documented (even roughly) ? hmm, no, > > I think we have some users facing this issue. > > Btw, I don't really care if users can't extend the schema when they can't > write on disk. But we can discuss about allowing this too. let me be a bit more clear here, from the API pov all that it needs is just a schema manager, so we can simply keep all the data in memory(assuming we don't want to update the schema) (Note: currently, API operates in this in-memory mode, so there is no extraction of LDIF files)
but for a embedded server the case is different, it requires a LDIF partition for which we need to extract the files on to the disk, ( cause LdifPartition currently works this way). To make this work in a container environment we have a fix. Kiran Ayyagari
