On Thu, Aug 5, 2010 at 8:28 PM, Kiran Ayyagari <[email protected]> wrote:
> On Thu, Aug 5, 2010 at 8:55 PM, Emmanuel Lecharny <[email protected]> > wrote: > > The best place when it comes to think about the future... > > > > So we will have some potential issues with the LDAP API : as we now have > a > > schema Aware, we have to load the schema into a SchemaManager. Right now, > > all the schema is stored into a subproject (shared/ldap-schema) as LDIF > > files. When we try to initialize the schemaManager, we first extract the > > LDIF to the disk. > > > > This is *very* bad ! When one will try to embed the API (in tomcat for > > instance), one will face serious issues as the file system might not be > > writable. > hmm, no, at least we can have access to the container's or system's > temporary area > > > > We must fix that so that we can just read the LDIF directly from the > > resources without having to extract the LDIF files to disk. That also > means > > we must not try to update the LDIF on disk when modifying the schema. > currently the client cannot update the schema but IMO we should add > such a feature > sooner or later. For this to work efficiently it is good to have the > schema stored on disk > (just like the way Studio does it) > > > > On solution would be to use the AvlPartition to back the LdifPartition. > yeah but currently LdifPartition can only work if the files are stored on > disk > > > > I'm not 100% sure that we don't currently have a workaround for this > > problem, but if so, it must be clearly documented. Otherwise, we have to > > provided a way to fix it. > we do have a workaround/fix for this (by setting a special VM option > specifying the location of the > schema directory or the jar file in which schema files are present) > > This workaround IMHO is sufficient for embedding into containers. I would not alter the whole server schema loading behavior just for this very special case. Alex
