directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <radovan.seman...@evolveum.com>
Subject Re: Fwd: Re: [LDAP API] Schema aware connection
Date Wed, 16 Sep 2015 08:46:19 GMT
Hi,

I agree, of course.

Just a bit more information. Currently there is a way how to do this ... 
kind of ...

			boolean schemaQuirksMode = ....
     			DefaultSchemaLoader schemaLoader = new DefaultSchemaLoader(connection, schemaQuirksMode);
     			DefaultSchemaManager schemaManager = new DefaultSchemaManager(schemaLoader);
     			try {
     				if (schemaQuirksMode) {
         				schemaManager.setRelaxed();
         				schemaManager.loadAllEnabledRelaxed();
     				} else {
     					schemaManager.loadAllEnabled();
     				}
				} catch (Exception e) {
					throw new ConnectorIOException(e.getMessage(), e);
				}
     			if ( !schemaManager.getErrors().isEmpty() ) {
     				if (schemaQuirksMode) {
     					LOG.ok("There are {0} schema errors, but we are in quirks mode so we are ignoring
them", defSchemaManager.getErrors().size());
     					for (Throwable error: schemaManager.getErrors()) {
     						LOG.ok("Schema error (ignored): {0}: {1}", error.getClass().getName(), error.getMessage());
     					}
     				} else {
     					throw new ConnectorIOException("Errors loading schema "+schemaManager.getErrors());
     				}
     			}


This code works even with bad LDAP servers. But .... there are some 
drawbacks:

1) The schemaManager cannot be attached to the connection. I.e. you must 
not call connection.setSchemaManager(schemaManager). Otherwise the LDAP 
operations will fail on many places as the loaded schema is 
inconsistent. I guess that this is mostly OK. If the schema is not 
consistent then it cannot be expected that it will work normally for all 
the cases. But I believe it should work normally unless a the specific 
inconsistency is encountered. I.e. if there are schema inconsistencies 
in an attribute/syntax that is never used then th API should work 
normally even with inconsistent schema.

2) Some errors do not appear in the error list 
(schemaManager.getErrors()). E.g. the OID syntax error that I was fixing 
recently. The error handling in schema processing is a bit inconsistent. 
But I think this can be fixed in an evolutionary fashion.

3) This all not very user-friendly. The modifications that Emmanuel 
suggested seem to be a good improvements.

4) We have quirks mode and relaxed mode. I've realized that quicks mode 
is for parsing and relaxed mode is for schema processing and validation. 
But, do we need to expose both to the API user? Maybe relaxed mode 
should imply quirks mode.

To be more specific, I think we need this (ideally):

connection.loadSchema(mode)

... and internal implementation will set up quirks/relaxed mode as 
appropriate. The current code is not very clean and I think that we will 
need some "leeway" until we figure out what exactly needs to be done 
here. Therefore we should provide a simple facade to API users that will 
not change even if we change in internal interfaces (SchemaManager, 
SchemaLoader).

To go one step further I guess we also need to clean up the 
SchemaManager and SchemaLoader a bit. E.g. DefaultSchemaManager has 
setRelaxed(), loadAllEnabled() and loadAllEnabledRelaxed(). One of these 
methods seems to be redundant. I would expect either to use 
setRelaxed(true) and then loadAllEnabled(), but as far as I can remember 
that does not work. Speaking politically correctly this is a little bit 
of a mess :-) I deserves to be cleaned up.

-- 
Radovan Semancik
Software Architect
evolveum.com





On 09/15/2015 02:46 PM, Emmanuel Lécharny wrote:
> Le 15/09/15 14:39, Emmanuel Lécharny a écrit :
>> Forwarding this mail who deserves to be sent to API@directory.a.o...
>>
>>
>>
>> Le 15/09/15 12:03, Emmanuel Lécharny a écrit :
>>> Hi,
>>>
>>> Radovan has added some way to support schemas that have some slight
>>> differences with the RFC, using the quirkmode flag. If you are using
>>> tehe NetworkLdapConnection, it works this way :
>>>
>>>                      SchemaLoader schemaLoader = new DefaultSchemaLoader(
>>> ldapConnection, true );
>>>                      ldapConnection.loadSchema( schemaLoader );
>>>
>>> Thats fine, except if you have declared your ldapConnection thsi way :
>>>
>>>                      LdapConnection ldapConnection = new
>>> LdapNetworkConnection( server.getServerName(), server.getPort() );
>>>
>>> because the LdapConnection interface does not expose the loadSchema(
>>> schemaLoader ) method.
>>>
>>> I suggest we expose it.
>>>
>>> I also think we should extend the ldapConnection.loadSchema() method, in
>>> order to spare the users from declaring a SchemaLoader on their own.
>>> That would make the code looks like :
>>>
>>>
>>>                      ldapConnection.loadSchemaRelaxed();
>>>
>>> which would replace
>>>
>>>                      SchemaLoader schemaLoader = new DefaultSchemaLoader(
>>> ldapConnection, true );
>>>                      ldapConnection.loadSchema( schemaLoader );
>> It's a bit more complex that just using the quirkmode (which just relax
>> the schema syntax). Sometime, we want to accept some inconsistencies in
>> the schema itself. The relaxed mode is there to accept such schema, but
>> it's not exposed.
>>
>> Typically, the loadSchema() methods starts with :
>>
>>
>>      public void loadSchema( SchemaLoader loader ) throws LdapException
>>      {
>>          try
>>          {
>>              SchemaManager tmp = new DefaultSchemaManager( loader );
>>             
>>              tmp.loadAllEnabled();
>>
>>              if ( !tmp.getErrors().isEmpty() )
>>              {
>>                  String msg = "there are errors while loading the schema";
>>                  LOG.error( msg + " {}", tmp.getErrors() );
>>                  throw new LdapException( msg );
>>              }
>>              ...
>>
>> which creates a SchemaManager in strict mode. Obviously, the
>> tmp.loadAllEnabled() will fail. We should propagate the 'relaxed' flag
>> down to the SchemaManager.
>>
>>
>>
>>
> I will give a clear example :
>
> when you connect to an OpenLDAP server, and fetch the schema, you will
> get a failure because some MatchingRule are using a Syntax which is not
> loaded. Typically, a standard OpenLDAP server with core, cosine and
> inetorgperson schemas will have 248 ATs, 34 OCs, and 72 Syntaxes (from
> cn=schema,ou=config). The same server will expose only 32 Syntaxes (but
> 248 ATs and 63 OCs. Go fish...)
>
> The 40 missing Syntaxes are syntaxes which have no associated
> validators. That does not mean those syntax can't be used, though. The
> pb is that we don't see them in the SchemaLoader, and we default by
> rejecting the load.
>
> At this point, one solution would be to signal those errors, but don't
> stop and use default elements to replace the missing ones (ie, defining
> a Syntax with no specific check).
>
> I see no other ways to deal with that, becauee as Radovan says, it won't
> be fixed any time soon...
>
> thoughts ?
>



Mime
View raw message