Le 18/06/15 00:59, Stefan Seelmann a écrit :
> On 06/17/2015 11:32 PM, Emmanuel Lécharny wrote:
>> Le 17/06/15 21:11, Stefan Seelmann a écrit :
>>> So you talk about the Schema Editor, right? 
>> no, in my case, I'm talking about the OpenLDAP config editor, which
>> tries to read the config from a running server.
> Oh. you use the
> org.apache.directory.studio.ldapbrowser.core.model.schema.Schema there.
> Now I understand your complaints. From my gut feeling I'd say that's no
> good idea, but I don't have a better idea currently. I'll try to have a
> closer look next weekend.

I still have to clarify my mind. AFAICT, there are many different schema
being loaded in Studio. At some point, we even read a default OpenLDAP
schema which is declared in
plugins/openldap.config.editor/src/main/resources/org/apache/directory/studio/openldap/config/openldapconfig.ldif,
and this schema was not up to date.

The key is that in order to manage the OpenLDAP configuration (and it's
the same thing for ApacheDS, btw), we need to handle two different cases :

- we are connected to a LDAP Server, and we can fetch the schema from it
- we are not connected to a LDAP server, but we still have to ba able to
manipulate the schema, so we need to have a local instance of a
SchemaManager that knows what are the AttributeTypes we can play with
for the config.

Of course, both mode should work but not collide. I'm not sure we do
that properly atm. Typically, I always work with a connected OpenLDAP
server (simply because I can't yet create a LDIF based config), but at
some point, we are reading the OpenLDAP config from the
openldapconfig.ldif, which is wrong.

There is something I have to fix here. Nevertheless, I think we should
view and manipulate only one single SchemaManager instance here,
regardless the way it's loaded. My perception is that this SchemaManager
should be associated directly with the Connection object, which is not
the case. wdyt ?


Reply via email to