You are viewing a plain text version of this content. The canonical link for it is here.
Posted to api@directory.apache.org by Gerald Turner <gt...@unzane.com> on 2013/08/21 02:07:40 UTC
Re: API behavior questions
Hello, I've been working with the client API for the past week and have
a few questions related to schema loading.
Emmanuel Lécharny <el...@gmail.com> writes:
> Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> 5) What needs to happen to have the results of calls to
>> LdapConnection.search(..) return entries for which isSchemaAware is
>> true?
> The LdapConnection must be schema aware itself.
>
> For that to happen, you just have to call the loadSchema() method :
>
> LdapConnection connection = new LdapNetworkConnection( "localhost", 389 );
> connection.loadSchema();
>
> Here, we will load the default schemas.
>
> You can use some specific schema by using :
>
> connection.loadSchema();
> connection.addSchema( "MySchema.schema" );
>
> where the "MySchema.schema" is a schema in OpenLDAP format.
>
> You can also use a SchemaLoader, but this get a bit too complex atm
> (and sadly, the associated method is not yet in the LdapConnection
> interface)
I've tried:
con.loadSchema()
((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
without much success until finally trying:
((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
with a File pointing at a modified local copy of the ApacheDS schema
directory.
It takes about 2 seconds load and is only associated with that one
connection.
· Are there other interfaces that can be used to only load the
SchemaManager _once_ and have it shared across connections?
· Can I safely use the SchemaManager after a connection has been
returned to the pool. (e.g. instantiating Dn and other objects that
take SchemaManager in their constructors - at a point in the application
where communication with the LDAP server is no longer necessary - doing
comparisons on data structures that have been cached in a session).
· I see a comment in DefaultSchemaLoader constructor: “TODO Handle
schema loading on other LDAP servers” — how difficult would it be to
implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
matter of banging strings around because core parsing already exists,
maybe I could have a go at it.
· Various times while parsing schemas (particularly while playing with
SchemaToLdif), I got rather ambiguous ParserExceptions. In a debugger I
could trace the exception to a rather detailed ANTLR exception,
unfortunately these root causes are being discarded. Suggestion: Please
chain exceptions!
· I feel like I'm going down a rabbit hole - all I really needed was to
get case-insensitive equality on Dn comparison. Our server arbitrarily
returns “o=People” and sometimes “o=people”. Making the LDAP Client API
schema aware solves this, but so would hacking in toLowerCase in a
bazillion places. Maybe implementing a dumbed down SchemaManager that
returned some very naïve and static set of assumptions for common
attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’ would work.
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Emmanuel Lécharny <el...@gmail.com> writes:
> Le 8/22/13 8:11 PM, Gerald Turner a écrit :
>> Gerald Turner <gt...@unzane.com> writes: Sorry about the huge
>> mailing list post, I went ahead and created bug DIRAPI-156
>> instead. I'm trying like mad to get the ApacheDS client API schema
>> aware with our OpenLDAP server contianing a couple custom
>> attributes/classes. I can proceed with the hacked copy of the
>> 'schema' folder and use LdifSchemaLoader(File) - unfortunately this
>> will be ugly as far as deployment goes.
> Sorry for not beng able to help... I wrote some part of his API, but I
> have no time to give ou some direction, as I leave for one week...
>
> The key, here, is to create the correct schemaLoader and to use it to
> initialize the schemaManager :
>
> LdifSchemaLoader loader = new LdifSchemaLoader( new File( workingDirectory, "schema" ) );
> SchemaManager sm = new DefaultSchemaManager( loader );
>
> boolean loaded = sm.loadAllEnabled();
>
> The first step creates a loader that read the schema from ldif files
> on the disk. The second step creates the schemamanager. the third step
> loads the enabled schemas to generate a valid schemaManager that can
> be use by the API.
>
> The tricky part here is that the schema must be stored in a LDIF
> format which is specific to ApacheDS.
>
> Or you can use a SchemaEditorSchemaLoader, which is capable of
> converting OpenLDAP formatted schema to standard ApacheDS entries
> (this should work, I never tested it).
>
> I'm not sure tht it helps, but I would be pleased to help when I'll be
> back from vacations (in one week).
Thanks Emmanuel, I basically have what you're talking about implemented,
also from advice given by Kiran and Stefan.
I've come down to three flavors, in order of preference, unfortunately
the first two don't work:
// Load schema:
// - Using RFC4512
// Bug: https://issues.apache.org/jira/browse/DIRAPI-154
//con.loadSchema();
// - Using ApacheDS native schema + custom OpenLDAP schema
// Bug: https://issues.apache.org/jira/browse/DIRAPI-156
//con.loadSchema(new JarLdifSchemaLoader());
//con.addSchema(getFileResource("openldap-schema/xocust.schema"));
// - Using modified copy of ApacheDS native schema
con.loadSchema(new LdifSchemaLoader(getFileResource("apacheds-schema")));
The third flavor works, but it's going to be a deployment problem. I
want to pack the schema directory in a JAR, but don't think there's a
way to get a JAR Resource to a File required by the LdifSchemaLoader
constructor, so I may have to do something silly like copy them to some
external path on the servers.
I like your concept of initializing a SchemaManager outside of
LdapNetworkConnection loadSchema/addSchema methods. Too bad
LdapNetworkConnection doesn't have setSchemaManager (only getter) -
perhaps that would be a simple solution to DIRAPI-153
https://issues.apache.org/jira/browse/DIRAPI-153
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Emmanuel Lécharny <el...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Le 8/22/13 8:11 PM, Gerald Turner a écrit :
> Gerald Turner <gt...@unzane.com> writes:
> Sorry about the huge mailing list post, I went ahead and created bug
DIRAPI-156 instead. I'm trying like mad to get the ApacheDS client API
schema aware with our OpenLDAP server contianing a couple custom
attributes/classes. I can proceed with the hacked copy of the 'schema'
folder and use LdifSchemaLoader(File) - unfortunately this will be ugly
as far as deployment goes.
Sorry for not beng able to help... I wrote some part of his API, but I
have no time to give ou some direction, as I leave for one week...
The key, here, is to create the correct schemaLoader and to use it to
initialize the schemaManager :
LdifSchemaLoader loader = new LdifSchemaLoader( new File(
workingDirectory, "schema" ) );
SchemaManager sm = new DefaultSchemaManager( loader );
boolean loaded = sm.loadAllEnabled();
The first step creates a loader that read the schema from ldif files on
the disk. The second step creates the schemamanager. the third step
loads the enabled schemas to generate a valid schemaManager that can be
use by the API.
The tricky part here is that the schema must be stored in a LDIF format
which is specific to ApacheDS.
Or you can use a SchemaEditorSchemaLoader, which is capable of
converting OpenLDAP formatted schema to standard ApacheDS entries (this
should work, I never tested it).
I'm not sure tht it helps, but I would be pleased to help when I'll be
back from vacations (in one week).
- --
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJSFpjoAAoJEDFHTl58a3A0kkUP/3xxFnPt6dBAoqpsQ8pXGAWA
ErVWGzHmr+VJczuS5fYEN+Q1Y/0RVfF1YivmnAvhwTHq/edrbN+CnT8n/Nc6eJxj
5y4h2558DGEaFqF6f5PzAKzigI1gkYvjey2rpss0sFIqLW1f58sNadfYKFloIRT7
PglLva3yxOqgpt3rrjvIj4kCATg2GIvTL1ugTNBhZkcdO0TBRSsOcxORCCN4SUg0
Mt5oK2dVqoPBlth+aIUz14FYympk42WjIZc7YNCIxTKN4ixZxh+4CjUqEoxoOks/
vrXAXEgOELPmmYj7qjUc082IU95cmqa1Qvvq6Ytf2MF3lCSlrlwbHz3mjPVMcLMS
Yom+TdNauusRA3DjIweRpf7rCaNI3BIwd0omChPuQvk7MArYvEpe2odl6BuWdEsL
Q0ZwXw7QT0Biol/csFIdaIMrDmbajIQmt11gQge3PSyP/q1W+AwwVCG8pYjUuJMW
AtXgVsDIan+Ak5Cvmt5IGA31aYuy2Ivkp+oWH5ajT7wgcZQeasNLKvkpl1RDb9iT
8Vql8yoluPra4Aq97KOz9U/Bwf6REKW1cGUx00rlMScfaS12RBZiP1+lkTdDRLEF
UbLRrrf6KGfK07KlpajBr+PsTlSuRwEjw/wlsujjzZPuhW+o+dTanLnDOvNRDkE6
QJHGuQI0OpwcQRiC7EOG
=LUVg
-----END PGP SIGNATURE-----
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Gerald Turner <gt...@unzane.com> writes:
> Kiran Ayyagari <ka...@apache.org> writes:
>> On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
>>> Kiran Ayyagari <ka...@apache.org> writes:
>>> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>>> >> Emmanuel Lécharny <el...@gmail.com> writes:
>>> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>>> >> >> 5) What needs to happen to have the results of calls to
>>> >> >> LdapConnection.search(..) return entries for which
>>> >> >> isSchemaAware is true?
>>> >> > The LdapConnection must be schema aware itself.
>>> >> >
>>> >> > For that to happen, you just have to call the loadSchema()
>>> >> > method :
>>> >> >
>>> >> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>>> >> > connection.loadSchema();
>>> >> >
>>> >> > Here, we will load the default schemas.
>>> >> >
>>> >> > You can use some specific schema by using :
>>> >> >
>>> >> > connection.loadSchema();
>>> >> > connection.addSchema( "MySchema.schema" );
>>> >> >
>>> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
>>> >> >
>>> >> > You can also use a SchemaLoader, but this get a bit too complex
>>> >> > atm (and sadly, the associated method is not yet in the
>>> >> > LdapConnection interface)
>>> >>
>>> >> I've tried:
>>> >>
>>> >> con.loadSchema()
>>> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>>> >> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>>> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>>> >>
>>> >> without much success until finally trying:
>>> >
>>> > what was the error encountered while using above schema loaders?
>>> > (are using a then inside a web application?)
>>>
>>> The errors were really just learning exercises ;-)
>>>
>>> Mostly from JUnit in Eclipse, but eventually in a web application on
>>> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the
>>> schema directory in api-ldap-schema-data-1.0.0-M20.jar, I'll
>>> investigate this further.
>>
>> this is most likely due to an issue with classloaders
>
> Yep, I now have JarLdifSchemaLoader loading the schema just fine.
>
> However now I believe I may be onto a real bug again.
>
> I'm loading the schema with code like this:
>
> con.loadSchema(new JarLdifSchemaLoader());
> con.addSchema("custom.schema");
>
> Later an exception is thrown while I'm handling some search results.
> The entry in question looks like:
>
> dn: cn=ICRCSSTAccess,ou=Roles,o=jaas,dc=xoint,dc=net
> objectClass: groupOfNames
> cn: ICRCSSTAccess
> member: uid=gturner,ou=people,dc=xoint,dc=net
> member: uuid=98bb35ee-9ff3-444f-9925-7fe762810d50,o=Asus,ou=customers,dc=xoint,dc=net
>
> The code where the exception is thrown looks like this:
>
> Attribute memberAttribute = entry.get("member");
> if (memberAttribute != null)
> for (Iterator<Value<?>> iterator = memberAttribute.iterator();
> iterator.hasNext();) {
> @SuppressWarnings("unchecked")
> Value<String> value = (Value<String>) iterator.next();
> String member = value.getValue();
> Dn memberDn = new Dn(context.getSchemaManager(), member);
> members.add(memberDn);
> }
>
> It is the Dn instantiation that throws the following stacktrace:
>
> org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
> at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1106)
> at org.apache.directory.api.ldap.model.name.Dn.rdnOidToName(Dn.java:1143)
> at org.apache.directory.api.ldap.model.name.Rdn.apply(Rdn.java:454)
> at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1202)
> at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1281)
> at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:287)
> at net.xoint.usermanager.model.Role.<init>(Role.java:45)
> at net.xoint.usermanager.model.LDAPLoader.loadRoles(LDAPLoader.java:75)
> at net.xoint.usermanager.model.LDAPLoader.load(LDAPLoader.java:52)
> at net.xoint.usermanager.UserManagerTest.test2(UserManagerTest.java:134)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
> at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:476)
> at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1100)
> ... 36 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:293)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1604)
> at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:470)
> ... 37 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:289)
> ... 40 more
>
> OID 1.3.6.1.4.1.38541.2.1.3 is the uuid attribute that is part of a
> member DN. "custom.schema" defines it as follows:
>
> attributetype ( 1.3.6.1.4.1.38541.2.1.3
> NAME 'uuid'
> DESC 'The customer UUID'
> EQUALITY UUIDMatch
> SYNTAX 1.3.6.1.1.16.1
> SINGLE-VALUE )
>
> While scrutinizing the source, looking for why this attribute wouldn't
> be found in the DefaultSchemaObjectRegistry#byName Map for the
> AttributeTypeRegistry, I'm beginning to suspect that somewhere around
> where LdapNetworkConnection#addSchema is calling
> AttributeTypeRegistry#addMappingFor, it hasn't quite finished the job,
> perhaps something like calling AttributeTypeRegistry#register (which
> seems to be the only method that put's into the byName Map).
>
> Note that I had been using a custom hacked up local copy of the schema
> folder with my custom jammed in, this *was* working, however I'd much
> rather use the stock schema folder (JarLdifSchemaLoader) and one file
> containing my custom schema.
Sorry about the huge mailing list post, I went ahead and created bug
DIRAPI-156 instead.
I'm trying like mad to get the ApacheDS client API schema aware with our
OpenLDAP server contianing a couple custom attributes/classes. I can
proceed with the hacked copy of the 'schema' folder and use
LdifSchemaLoader(File) - unfortunately this will be ugly as far as
deployment goes.
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Gerald Turner <gt...@unzane.com> writes:
> Kiran Ayyagari <ka...@apache.org> writes:
>> On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
>>> Kiran Ayyagari <ka...@apache.org> writes:
>>> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>>> >> Emmanuel Lécharny <el...@gmail.com> writes:
>>> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>>> >> >> 5) What needs to happen to have the results of calls to
>>> >> >> LdapConnection.search(..) return entries for which
>>> >> >> isSchemaAware is true?
>>> >> > The LdapConnection must be schema aware itself.
>>> >> >
>>> >> > For that to happen, you just have to call the loadSchema()
>>> >> > method :
>>> >> >
>>> >> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>>> >> > connection.loadSchema();
>>> >> >
>>> >> > Here, we will load the default schemas.
>>> >> >
>>> >> > You can use some specific schema by using :
>>> >> >
>>> >> > connection.loadSchema();
>>> >> > connection.addSchema( "MySchema.schema" );
>>> >> >
>>> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
>>> >> >
>>> >> > You can also use a SchemaLoader, but this get a bit too complex
>>> >> > atm (and sadly, the associated method is not yet in the
>>> >> > LdapConnection interface)
>>> >>
>>> >> I've tried:
>>> >>
>>> >> con.loadSchema()
>>> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>>> >> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>>> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>>> >>
>>> >> without much success until finally trying:
>>> >
>>> > what was the error encountered while using above schema loaders?
>>> > (are using a then inside a web application?)
>>>
>>> The errors were really just learning exercises ;-)
>>>
>>> Mostly from JUnit in Eclipse, but eventually in a web application on
>>> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the
>>> schema directory in api-ldap-schema-data-1.0.0-M20.jar, I'll
>>> investigate this further.
>>
>> this is most likely due to an issue with classloaders
>
> Yep, I now have JarLdifSchemaLoader loading the schema just fine.
>
> However now I believe I may be onto a real bug again.
>
> I'm loading the schema with code like this:
>
> con.loadSchema(new JarLdifSchemaLoader());
> con.addSchema("custom.schema");
>
> Later an exception is thrown while I'm handling some search results.
> The entry in question looks like:
>
> dn: cn=ICRCSSTAccess,ou=Roles,o=jaas,dc=xoint,dc=net
> objectClass: groupOfNames
> cn: ICRCSSTAccess
> member: uid=gturner,ou=people,dc=xoint,dc=net
> member: uuid=98bb35ee-9ff3-444f-9925-7fe762810d50,o=Asus,ou=customers,dc=xoint,dc=net
>
> The code where the exception is thrown looks like this:
>
> Attribute memberAttribute = entry.get("member");
> if (memberAttribute != null)
> for (Iterator<Value<?>> iterator = memberAttribute.iterator();
> iterator.hasNext();) {
> @SuppressWarnings("unchecked")
> Value<String> value = (Value<String>) iterator.next();
> String member = value.getValue();
> Dn memberDn = new Dn(context.getSchemaManager(), member);
> members.add(memberDn);
> }
>
> It is the Dn instantiation that throws the following stacktrace:
>
> org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
> at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1106)
> at org.apache.directory.api.ldap.model.name.Dn.rdnOidToName(Dn.java:1143)
> at org.apache.directory.api.ldap.model.name.Rdn.apply(Rdn.java:454)
> at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1202)
> at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1281)
> at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:287)
> at net.xoint.usermanager.model.Role.<init>(Role.java:45)
> at net.xoint.usermanager.model.LDAPLoader.loadRoles(LDAPLoader.java:75)
> at net.xoint.usermanager.model.LDAPLoader.load(LDAPLoader.java:52)
> at net.xoint.usermanager.UserManagerTest.test2(UserManagerTest.java:134)
> Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
> at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:476)
> at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1100)
> ... 36 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:293)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
> at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1604)
> at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:470)
> ... 37 more
> Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
> at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
> at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:289)
> ... 40 more
>
> OID 1.3.6.1.4.1.38541.2.1.3 is the uuid attribute that is part of a
> member DN. "custom.schema" defines it as follows:
>
> attributetype ( 1.3.6.1.4.1.38541.2.1.3
> NAME 'uuid'
> DESC 'The customer UUID'
> EQUALITY UUIDMatch
> SYNTAX 1.3.6.1.1.16.1
> SINGLE-VALUE )
>
> While scrutinizing the source, looking for why this attribute wouldn't
> be found in the DefaultSchemaObjectRegistry#byName Map for the
> AttributeTypeRegistry, I'm beginning to suspect that somewhere around
> where LdapNetworkConnection#addSchema is calling
> AttributeTypeRegistry#addMappingFor, it hasn't quite finished the job,
> perhaps something like calling AttributeTypeRegistry#register (which
> seems to be the only method that put's into the byName Map).
>
> Note that I had been using a custom hacked up local copy of the schema
> folder with my custom jammed in, this *was* working, however I'd much
> rather use the stock schema folder (JarLdifSchemaLoader) and one file
> containing my custom schema.
Sorry about the huge mailing list post, I went ahead and created bug
DIRAPI-156 instead.
I'm trying like mad to get the ApacheDS client API schema aware with our
OpenLDAP server contianing a couple custom attributes/classes. I can
proceed with the hacked copy of the 'schema' folder and use
LdifSchemaLoader(File) - unfortunately this will be ugly as far as
deployment goes.
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Kiran Ayyagari <ka...@apache.org> writes:
> On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
>> Kiran Ayyagari <ka...@apache.org> writes:
>> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>> >> Emmanuel Lécharny <el...@gmail.com> writes:
>> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> >> >> 5) What needs to happen to have the results of calls to
>> >> >> LdapConnection.search(..) return entries for which
>> >> >> isSchemaAware is true?
>> >> > The LdapConnection must be schema aware itself.
>> >> >
>> >> > For that to happen, you just have to call the loadSchema()
>> >> > method :
>> >> >
>> >> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>> >> > connection.loadSchema();
>> >> >
>> >> > Here, we will load the default schemas.
>> >> >
>> >> > You can use some specific schema by using :
>> >> >
>> >> > connection.loadSchema();
>> >> > connection.addSchema( "MySchema.schema" );
>> >> >
>> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
>> >> >
>> >> > You can also use a SchemaLoader, but this get a bit too complex
>> >> > atm (and sadly, the associated method is not yet in the
>> >> > LdapConnection interface)
>> >>
>> >> I've tried:
>> >>
>> >> con.loadSchema()
>> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>> >> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>> >>
>> >> without much success until finally trying:
>> >
>> > what was the error encountered while using above schema loaders?
>> > (are using a then inside a web application?)
>>
>> The errors were really just learning exercises ;-)
>>
>> Mostly from JUnit in Eclipse, but eventually in a web application on
>> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
>> directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate
>> this further.
>
> this is most likely due to an issue with classloaders
Yep, I now have JarLdifSchemaLoader loading the schema just fine.
However now I believe I may be onto a real bug again.
I'm loading the schema with code like this:
con.loadSchema(new JarLdifSchemaLoader());
con.addSchema("custom.schema");
Later an exception is thrown while I'm handling some search results.
The entry in question looks like:
dn: cn=ICRCSSTAccess,ou=Roles,o=jaas,dc=xoint,dc=net
objectClass: groupOfNames
cn: ICRCSSTAccess
member: uid=gturner,ou=people,dc=xoint,dc=net
member: uuid=98bb35ee-9ff3-444f-9925-7fe762810d50,o=Asus,ou=customers,dc=xoint,dc=net
The code where the exception is thrown looks like this:
Attribute memberAttribute = entry.get("member");
if (memberAttribute != null)
for (Iterator<Value<?>> iterator = memberAttribute.iterator();
iterator.hasNext();) {
@SuppressWarnings("unchecked")
Value<String> value = (Value<String>) iterator.next();
String member = value.getValue();
Dn memberDn = new Dn(context.getSchemaManager(), member);
members.add(memberDn);
}
It is the Dn instantiation that throws the following stacktrace:
org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1106)
at org.apache.directory.api.ldap.model.name.Dn.rdnOidToName(Dn.java:1143)
at org.apache.directory.api.ldap.model.name.Rdn.apply(Rdn.java:454)
at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1202)
at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1281)
at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:287)
at net.xoint.usermanager.model.Role.<init>(Role.java:45)
at net.xoint.usermanager.model.LDAPLoader.loadRoles(LDAPLoader.java:75)
at net.xoint.usermanager.model.LDAPLoader.load(LDAPLoader.java:52)
at net.xoint.usermanager.UserManagerTest.test2(UserManagerTest.java:134)
Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:476)
at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1100)
... 36 more
Caused by: org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:293)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1604)
at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:470)
... 37 more
Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:289)
... 40 more
OID 1.3.6.1.4.1.38541.2.1.3 is the uuid attribute that is part of a
member DN. "custom.schema" defines it as follows:
attributetype ( 1.3.6.1.4.1.38541.2.1.3
NAME 'uuid'
DESC 'The customer UUID'
EQUALITY UUIDMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
While scrutinizing the source, looking for why this attribute wouldn't
be found in the DefaultSchemaObjectRegistry#byName Map for the
AttributeTypeRegistry, I'm beginning to suspect that somewhere around
where LdapNetworkConnection#addSchema is calling
AttributeTypeRegistry#addMappingFor, it hasn't quite finished the job,
perhaps something like calling AttributeTypeRegistry#register (which
seems to be the only method that put's into the byName Map).
Note that I had been using a custom hacked up local copy of the schema
folder with my custom jammed in, this *was* working, however I'd much
rather use the stock schema folder (JarLdifSchemaLoader) and one file
containing my custom schema.
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Kiran Ayyagari <ka...@apache.org> writes:
> On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
>> Kiran Ayyagari <ka...@apache.org> writes:
>> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>> >> Emmanuel Lécharny <el...@gmail.com> writes:
>> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> >> >> 5) What needs to happen to have the results of calls to
>> >> >> LdapConnection.search(..) return entries for which
>> >> >> isSchemaAware is true?
>> >> > The LdapConnection must be schema aware itself.
>> >> >
>> >> > For that to happen, you just have to call the loadSchema()
>> >> > method :
>> >> >
>> >> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>> >> > connection.loadSchema();
>> >> >
>> >> > Here, we will load the default schemas.
>> >> >
>> >> > You can use some specific schema by using :
>> >> >
>> >> > connection.loadSchema();
>> >> > connection.addSchema( "MySchema.schema" );
>> >> >
>> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
>> >> >
>> >> > You can also use a SchemaLoader, but this get a bit too complex
>> >> > atm (and sadly, the associated method is not yet in the
>> >> > LdapConnection interface)
>> >>
>> >> I've tried:
>> >>
>> >> con.loadSchema()
>> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>> >> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>> >>
>> >> without much success until finally trying:
>> >
>> > what was the error encountered while using above schema loaders?
>> > (are using a then inside a web application?)
>>
>> The errors were really just learning exercises ;-)
>>
>> Mostly from JUnit in Eclipse, but eventually in a web application on
>> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
>> directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate
>> this further.
>
> this is most likely due to an issue with classloaders
Yep, I now have JarLdifSchemaLoader loading the schema just fine.
However now I believe I may be onto a real bug again.
I'm loading the schema with code like this:
con.loadSchema(new JarLdifSchemaLoader());
con.addSchema("custom.schema");
Later an exception is thrown while I'm handling some search results.
The entry in question looks like:
dn: cn=ICRCSSTAccess,ou=Roles,o=jaas,dc=xoint,dc=net
objectClass: groupOfNames
cn: ICRCSSTAccess
member: uid=gturner,ou=people,dc=xoint,dc=net
member: uuid=98bb35ee-9ff3-444f-9925-7fe762810d50,o=Asus,ou=customers,dc=xoint,dc=net
The code where the exception is thrown looks like this:
Attribute memberAttribute = entry.get("member");
if (memberAttribute != null)
for (Iterator<Value<?>> iterator = memberAttribute.iterator();
iterator.hasNext();) {
@SuppressWarnings("unchecked")
Value<String> value = (Value<String>) iterator.next();
String member = value.getValue();
Dn memberDn = new Dn(context.getSchemaManager(), member);
members.add(memberDn);
}
It is the Dn instantiation that throws the following stacktrace:
org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1106)
at org.apache.directory.api.ldap.model.name.Dn.rdnOidToName(Dn.java:1143)
at org.apache.directory.api.ldap.model.name.Rdn.apply(Rdn.java:454)
at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1202)
at org.apache.directory.api.ldap.model.name.Dn.apply(Dn.java:1281)
at org.apache.directory.api.ldap.model.name.Dn.<init>(Dn.java:287)
at net.xoint.usermanager.model.Role.<init>(Role.java:45)
at net.xoint.usermanager.model.LDAPLoader.loadRoles(LDAPLoader.java:75)
at net.xoint.usermanager.model.LDAPLoader.load(LDAPLoader.java:52)
at net.xoint.usermanager.UserManagerTest.test2(UserManagerTest.java:134)
Caused by: org.apache.directory.api.ldap.model.exception.LdapInvalidDnException: ERR_04188 The type cannot be empty or null
at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:476)
at org.apache.directory.api.ldap.model.name.Dn.atavOidToName(Dn.java:1100)
... 36 more
Caused by: org.apache.directory.api.ldap.model.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:293)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:47)
at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.lookupAttributeTypeRegistry(DefaultSchemaManager.java:1604)
at org.apache.directory.api.ldap.model.name.Ava.apply(Ava.java:470)
... 37 more
Caused by: org.apache.directory.api.ldap.model.exception.LdapException: ERR_04269 ATTRIBUTE_TYPE for OID 1.3.6.1.4.1.38541.2.1.3 does not exist!
at org.apache.directory.api.ldap.model.schema.registries.DefaultSchemaObjectRegistry.lookup(DefaultSchemaObjectRegistry.java:176)
at org.apache.directory.api.ldap.model.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:289)
... 40 more
OID 1.3.6.1.4.1.38541.2.1.3 is the uuid attribute that is part of a
member DN. "custom.schema" defines it as follows:
attributetype ( 1.3.6.1.4.1.38541.2.1.3
NAME 'uuid'
DESC 'The customer UUID'
EQUALITY UUIDMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
While scrutinizing the source, looking for why this attribute wouldn't
be found in the DefaultSchemaObjectRegistry#byName Map for the
AttributeTypeRegistry, I'm beginning to suspect that somewhere around
where LdapNetworkConnection#addSchema is calling
AttributeTypeRegistry#addMappingFor, it hasn't quite finished the job,
perhaps something like calling AttributeTypeRegistry#register (which
seems to be the only method that put's into the byName Map).
Note that I had been using a custom hacked up local copy of the schema
folder with my custom jammed in, this *was* working, however I'd much
rather use the stock schema folder (JarLdifSchemaLoader) and one file
containing my custom schema.
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
> Kiran Ayyagari <ka...@apache.org> writes:
> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com>
> wrote:
> >> Emmanuel Lécharny <el...@gmail.com> writes:
> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
> >> >> 5) What needs to happen to have the results of calls to
> >> >> LdapConnection.search(..) return entries for which isSchemaAware
> >> >> is true?
> >> > The LdapConnection must be schema aware itself.
> >> >
> >> > For that to happen, you just have to call the loadSchema() method :
> >> >
> >> > LdapConnection connection = new LdapNetworkConnection( "localhost",
> 389);
> >> > connection.loadSchema();
> >> >
> >> > Here, we will load the default schemas.
> >> >
> >> > You can use some specific schema by using :
> >> >
> >> > connection.loadSchema();
> >> > connection.addSchema( "MySchema.schema" );
> >> >
> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
> >> >
> >> > You can also use a SchemaLoader, but this get a bit too complex atm
> >> > (and sadly, the associated method is not yet in the LdapConnection
> >> > interface)
> >>
> >> I've tried:
> >>
> >> con.loadSchema()
> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
> >> ((LdapNetworkConnection) con).loadSchema(new
> SingleLdifSchemaLoader(…))
> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
> >>
> >> without much success until finally trying:
> >
> > what was the error encountered while using above schema loaders? (are
> > using a then inside a web application?)
>
> The errors were really just learning exercises ;-)
>
> Mostly from JUnit in Eclipse, but eventually in a web application on
> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
> directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate this
> further.
>
> this is most likely due to an issue with classloaders
> >> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
> >>
> >> with a File pointing at a modified local copy of the ApacheDS schema
> >> directory.
> >>
> >> It takes about 2 seconds load and is only associated with that one
> >> connection.
> >>
> >> · Are there other interfaces that can be used to only load the
> >> SchemaManager _once_ and have it shared across connections?
> >
> > no, not at the moment, can you file a request for this in JIRA[1]
>
> DIRAPI-153
>
> >> · Can I safely use the SchemaManager after a connection has been
> >> returned to the pool. (e.g. instantiating Dn and other objects that
> >> take SchemaManager in their constructors - at a point in the
> >> application where communication with the LDAP server is no longer
> >> necessary - doing comparisons on data structures that have been
> >> cached in a session).
> >
> > yes, SchemaManager can be safely reused
>
> Great!
>
> >> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
> >> schema loading on other LDAP servers” — how difficult would it be to
> >> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
> >> matter of banging strings around because core parsing already exists,
> >> maybe I could have a go at it.
> >
> > Studio already has the capability to parse this type of schema,
> > perhaps we just need to move it to a utility class, another request
> > please
>
> DIRAPI-154
>
> >> · Various times while parsing schemas (particularly while playing
> >> with SchemaToLdif), I got rather ambiguous ParserExceptions. In a
> >> debugger I could trace the exception to a rather detailed ANTLR
> >> exception, unfortunately these root causes are being discarded.
> >> Suggestion: Please chain exceptions!
> >
> > it would be helpful if you can attach the stacktrace to a new bug
> > report
>
> DIRAPI-155
>
> >> · I feel like I'm going down a rabbit hole - all I really needed was
> >> to get case-insensitive equality on Dn comparison. Our server
> >> arbitrarily returns “o=People” and sometimes “o=people”. Making the
> >> LDAP Client API schema aware solves this, but so would hacking in
> >> toLowerCase in a bazillion places. Maybe implementing a dumbed down
> >> SchemaManager that returned some very naïve and static set of
> >> assumptions for common attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’
> >> would work.
> >
> > personally I use the JarLdifSchemaLoader in cases like these
> > Let us know if you have any issues with this schema loader in
> > your application environment
>
> I'll give this a try, thanks!
>
> thanks for the bug reports
> --
> Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
> GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
>
--
Kiran Ayyagari
http://keydap.com
Re: API behavior questions
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Aug 22, 2013 at 12:07 AM, Gerald Turner <gt...@unzane.com> wrote:
> Kiran Ayyagari <ka...@apache.org> writes:
> > On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com>
> wrote:
> >> Emmanuel Lécharny <el...@gmail.com> writes:
> >> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
> >> >> 5) What needs to happen to have the results of calls to
> >> >> LdapConnection.search(..) return entries for which isSchemaAware
> >> >> is true?
> >> > The LdapConnection must be schema aware itself.
> >> >
> >> > For that to happen, you just have to call the loadSchema() method :
> >> >
> >> > LdapConnection connection = new LdapNetworkConnection( "localhost",
> 389);
> >> > connection.loadSchema();
> >> >
> >> > Here, we will load the default schemas.
> >> >
> >> > You can use some specific schema by using :
> >> >
> >> > connection.loadSchema();
> >> > connection.addSchema( "MySchema.schema" );
> >> >
> >> > where the "MySchema.schema" is a schema in OpenLDAP format.
> >> >
> >> > You can also use a SchemaLoader, but this get a bit too complex atm
> >> > (and sadly, the associated method is not yet in the LdapConnection
> >> > interface)
> >>
> >> I've tried:
> >>
> >> con.loadSchema()
> >> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
> >> ((LdapNetworkConnection) con).loadSchema(new
> SingleLdifSchemaLoader(…))
> >> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
> >>
> >> without much success until finally trying:
> >
> > what was the error encountered while using above schema loaders? (are
> > using a then inside a web application?)
>
> The errors were really just learning exercises ;-)
>
> Mostly from JUnit in Eclipse, but eventually in a web application on
> JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
> directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate this
> further.
>
> this is most likely due to an issue with classloaders
> >> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
> >>
> >> with a File pointing at a modified local copy of the ApacheDS schema
> >> directory.
> >>
> >> It takes about 2 seconds load and is only associated with that one
> >> connection.
> >>
> >> · Are there other interfaces that can be used to only load the
> >> SchemaManager _once_ and have it shared across connections?
> >
> > no, not at the moment, can you file a request for this in JIRA[1]
>
> DIRAPI-153
>
> >> · Can I safely use the SchemaManager after a connection has been
> >> returned to the pool. (e.g. instantiating Dn and other objects that
> >> take SchemaManager in their constructors - at a point in the
> >> application where communication with the LDAP server is no longer
> >> necessary - doing comparisons on data structures that have been
> >> cached in a session).
> >
> > yes, SchemaManager can be safely reused
>
> Great!
>
> >> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
> >> schema loading on other LDAP servers” — how difficult would it be to
> >> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
> >> matter of banging strings around because core parsing already exists,
> >> maybe I could have a go at it.
> >
> > Studio already has the capability to parse this type of schema,
> > perhaps we just need to move it to a utility class, another request
> > please
>
> DIRAPI-154
>
> >> · Various times while parsing schemas (particularly while playing
> >> with SchemaToLdif), I got rather ambiguous ParserExceptions. In a
> >> debugger I could trace the exception to a rather detailed ANTLR
> >> exception, unfortunately these root causes are being discarded.
> >> Suggestion: Please chain exceptions!
> >
> > it would be helpful if you can attach the stacktrace to a new bug
> > report
>
> DIRAPI-155
>
> >> · I feel like I'm going down a rabbit hole - all I really needed was
> >> to get case-insensitive equality on Dn comparison. Our server
> >> arbitrarily returns “o=People” and sometimes “o=people”. Making the
> >> LDAP Client API schema aware solves this, but so would hacking in
> >> toLowerCase in a bazillion places. Maybe implementing a dumbed down
> >> SchemaManager that returned some very naïve and static set of
> >> assumptions for common attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’
> >> would work.
> >
> > personally I use the JarLdifSchemaLoader in cases like these
> > Let us know if you have any issues with this schema loader in
> > your application environment
>
> I'll give this a try, thanks!
>
> thanks for the bug reports
> --
> Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
> GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
>
--
Kiran Ayyagari
http://keydap.com
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Kiran Ayyagari <ka...@apache.org> writes:
> On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>> Emmanuel Lécharny <el...@gmail.com> writes:
>> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> >> 5) What needs to happen to have the results of calls to
>> >> LdapConnection.search(..) return entries for which isSchemaAware
>> >> is true?
>> > The LdapConnection must be schema aware itself.
>> >
>> > For that to happen, you just have to call the loadSchema() method :
>> >
>> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>> > connection.loadSchema();
>> >
>> > Here, we will load the default schemas.
>> >
>> > You can use some specific schema by using :
>> >
>> > connection.loadSchema();
>> > connection.addSchema( "MySchema.schema" );
>> >
>> > where the "MySchema.schema" is a schema in OpenLDAP format.
>> >
>> > You can also use a SchemaLoader, but this get a bit too complex atm
>> > (and sadly, the associated method is not yet in the LdapConnection
>> > interface)
>>
>> I've tried:
>>
>> con.loadSchema()
>> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>>
>> without much success until finally trying:
>
> what was the error encountered while using above schema loaders? (are
> using a then inside a web application?)
The errors were really just learning exercises ;-)
Mostly from JUnit in Eclipse, but eventually in a web application on
JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate this
further.
>> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
>>
>> with a File pointing at a modified local copy of the ApacheDS schema
>> directory.
>>
>> It takes about 2 seconds load and is only associated with that one
>> connection.
>>
>> · Are there other interfaces that can be used to only load the
>> SchemaManager _once_ and have it shared across connections?
>
> no, not at the moment, can you file a request for this in JIRA[1]
DIRAPI-153
>> · Can I safely use the SchemaManager after a connection has been
>> returned to the pool. (e.g. instantiating Dn and other objects that
>> take SchemaManager in their constructors - at a point in the
>> application where communication with the LDAP server is no longer
>> necessary - doing comparisons on data structures that have been
>> cached in a session).
>
> yes, SchemaManager can be safely reused
Great!
>> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
>> schema loading on other LDAP servers” — how difficult would it be to
>> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
>> matter of banging strings around because core parsing already exists,
>> maybe I could have a go at it.
>
> Studio already has the capability to parse this type of schema,
> perhaps we just need to move it to a utility class, another request
> please
DIRAPI-154
>> · Various times while parsing schemas (particularly while playing
>> with SchemaToLdif), I got rather ambiguous ParserExceptions. In a
>> debugger I could trace the exception to a rather detailed ANTLR
>> exception, unfortunately these root causes are being discarded.
>> Suggestion: Please chain exceptions!
>
> it would be helpful if you can attach the stacktrace to a new bug
> report
DIRAPI-155
>> · I feel like I'm going down a rabbit hole - all I really needed was
>> to get case-insensitive equality on Dn comparison. Our server
>> arbitrarily returns “o=People” and sometimes “o=people”. Making the
>> LDAP Client API schema aware solves this, but so would hacking in
>> toLowerCase in a bazillion places. Maybe implementing a dumbed down
>> SchemaManager that returned some very naïve and static set of
>> assumptions for common attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’
>> would work.
>
> personally I use the JarLdifSchemaLoader in cases like these
> Let us know if you have any issues with this schema loader in
> your application environment
I'll give this a try, thanks!
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Gerald Turner <gt...@unzane.com>.
Kiran Ayyagari <ka...@apache.org> writes:
> On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
>> Emmanuel Lécharny <el...@gmail.com> writes:
>> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
>> >> 5) What needs to happen to have the results of calls to
>> >> LdapConnection.search(..) return entries for which isSchemaAware
>> >> is true?
>> > The LdapConnection must be schema aware itself.
>> >
>> > For that to happen, you just have to call the loadSchema() method :
>> >
>> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389);
>> > connection.loadSchema();
>> >
>> > Here, we will load the default schemas.
>> >
>> > You can use some specific schema by using :
>> >
>> > connection.loadSchema();
>> > connection.addSchema( "MySchema.schema" );
>> >
>> > where the "MySchema.schema" is a schema in OpenLDAP format.
>> >
>> > You can also use a SchemaLoader, but this get a bit too complex atm
>> > (and sadly, the associated method is not yet in the LdapConnection
>> > interface)
>>
>> I've tried:
>>
>> con.loadSchema()
>> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
>> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
>> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>>
>> without much success until finally trying:
>
> what was the error encountered while using above schema loaders? (are
> using a then inside a web application?)
The errors were really just learning exercises ;-)
Mostly from JUnit in Eclipse, but eventually in a web application on
JBoss 7. It is odd that JarLdifSchemaLoader couldn't find the schema
directory in api-ldap-schema-data-1.0.0-M20.jar, I'll investigate this
further.
>> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
>>
>> with a File pointing at a modified local copy of the ApacheDS schema
>> directory.
>>
>> It takes about 2 seconds load and is only associated with that one
>> connection.
>>
>> · Are there other interfaces that can be used to only load the
>> SchemaManager _once_ and have it shared across connections?
>
> no, not at the moment, can you file a request for this in JIRA[1]
DIRAPI-153
>> · Can I safely use the SchemaManager after a connection has been
>> returned to the pool. (e.g. instantiating Dn and other objects that
>> take SchemaManager in their constructors - at a point in the
>> application where communication with the LDAP server is no longer
>> necessary - doing comparisons on data structures that have been
>> cached in a session).
>
> yes, SchemaManager can be safely reused
Great!
>> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
>> schema loading on other LDAP servers” — how difficult would it be to
>> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
>> matter of banging strings around because core parsing already exists,
>> maybe I could have a go at it.
>
> Studio already has the capability to parse this type of schema,
> perhaps we just need to move it to a utility class, another request
> please
DIRAPI-154
>> · Various times while parsing schemas (particularly while playing
>> with SchemaToLdif), I got rather ambiguous ParserExceptions. In a
>> debugger I could trace the exception to a rather detailed ANTLR
>> exception, unfortunately these root causes are being discarded.
>> Suggestion: Please chain exceptions!
>
> it would be helpful if you can attach the stacktrace to a new bug
> report
DIRAPI-155
>> · I feel like I'm going down a rabbit hole - all I really needed was
>> to get case-insensitive equality on Dn comparison. Our server
>> arbitrarily returns “o=People” and sometimes “o=people”. Making the
>> LDAP Client API schema aware solves this, but so would hacking in
>> toLowerCase in a bazillion places. Maybe implementing a dumbed down
>> SchemaManager that returned some very naïve and static set of
>> assumptions for common attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’
>> would work.
>
> personally I use the JarLdifSchemaLoader in cases like these
> Let us know if you have any issues with this schema loader in
> your application environment
I'll give this a try, thanks!
--
Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
Re: API behavior questions
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
> Hello, I've been working with the client API for the past week and have
> a few questions related to schema loading.
>
> Emmanuel Lécharny <el...@gmail.com> writes:
> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
> >> 5) What needs to happen to have the results of calls to
> >> LdapConnection.search(..) return entries for which isSchemaAware is
> >> true?
> > The LdapConnection must be schema aware itself.
> >
> > For that to happen, you just have to call the loadSchema() method :
> >
> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389
> );
> > connection.loadSchema();
> >
> > Here, we will load the default schemas.
> >
> > You can use some specific schema by using :
> >
> > connection.loadSchema();
> > connection.addSchema( "MySchema.schema" );
> >
> > where the "MySchema.schema" is a schema in OpenLDAP format.
> >
> > You can also use a SchemaLoader, but this get a bit too complex atm
> > (and sadly, the associated method is not yet in the LdapConnection
> > interface)
>
> I've tried:
>
> con.loadSchema()
> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>
> without much success until finally trying:
>
> what was the error encountered while using above schema loaders? (are
using a then inside
a web application?)
> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
>
> with a File pointing at a modified local copy of the ApacheDS schema
> directory.
>
> It takes about 2 seconds load and is only associated with that one
> connection.
>
> · Are there other interfaces that can be used to only load the
> SchemaManager _once_ and have it shared across connections?
>
> no, not at the moment, can you file a request for this in JIRA[1]
> · Can I safely use the SchemaManager after a connection has been
> returned to the pool. (e.g. instantiating Dn and other objects that
> take SchemaManager in their constructors - at a point in the application
> where communication with the LDAP server is no longer necessary - doing
> comparisons on data structures that have been cached in a session).
>
> yes, SchemaManager can be safely reused
> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
> schema loading on other LDAP servers” — how difficult would it be to
> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
> matter of banging strings around because core parsing already exists,
> maybe I could have a go at it.
>
> Studio already has the capability to parse this type of schema, perhaps we
just
need to move it to a utility class, another request please
> · Various times while parsing schemas (particularly while playing with
> SchemaToLdif), I got rather ambiguous ParserExceptions. In a debugger I
> could trace the exception to a rather detailed ANTLR exception,
> unfortunately these root causes are being discarded. Suggestion: Please
> chain exceptions!
>
> it would be helpful if you can attach the stacktrace to a new bug report
> · I feel like I'm going down a rabbit hole - all I really needed was to
> get case-insensitive equality on Dn comparison. Our server arbitrarily
> returns “o=People” and sometimes “o=people”. Making the LDAP Client API
> schema aware solves this, but so would hacking in toLowerCase in a
> bazillion places. Maybe implementing a dumbed down SchemaManager that
> returned some very naïve and static set of assumptions for common
> attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’ would work.
>
> personally I use the JarLdifSchemaLoader in cases like these
Let us know if you have any issues with this schema loader in
your application environment
[1] https://issues.apache.org/jira/browse/DIRAPI
> --
> Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
> GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
>
--
Kiran Ayyagari
http://keydap.com
Re: API behavior questions
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Aug 21, 2013 at 5:37 AM, Gerald Turner <gt...@unzane.com> wrote:
> Hello, I've been working with the client API for the past week and have
> a few questions related to schema loading.
>
> Emmanuel Lécharny <el...@gmail.com> writes:
> > Le 7/26/13 12:01 AM, Richard Sand a écrit :
> >> 5) What needs to happen to have the results of calls to
> >> LdapConnection.search(..) return entries for which isSchemaAware is
> >> true?
> > The LdapConnection must be schema aware itself.
> >
> > For that to happen, you just have to call the loadSchema() method :
> >
> > LdapConnection connection = new LdapNetworkConnection( "localhost", 389
> );
> > connection.loadSchema();
> >
> > Here, we will load the default schemas.
> >
> > You can use some specific schema by using :
> >
> > connection.loadSchema();
> > connection.addSchema( "MySchema.schema" );
> >
> > where the "MySchema.schema" is a schema in OpenLDAP format.
> >
> > You can also use a SchemaLoader, but this get a bit too complex atm
> > (and sadly, the associated method is not yet in the LdapConnection
> > interface)
>
> I've tried:
>
> con.loadSchema()
> ((LdapNetworkConnection) con).loadSchema(new DefaultSchemaLoader(…))
> ((LdapNetworkConnection) con).loadSchema(new SingleLdifSchemaLoader(…))
> ((LdapNetworkConnection) con).loadSchema(new JarLdifSchemaLoader(…))
>
> without much success until finally trying:
>
> what was the error encountered while using above schema loaders? (are
using a then inside
a web application?)
> ((LdapNetworkConnection) con).loadSchema(new LdifSchemaLoader(…))
>
> with a File pointing at a modified local copy of the ApacheDS schema
> directory.
>
> It takes about 2 seconds load and is only associated with that one
> connection.
>
> · Are there other interfaces that can be used to only load the
> SchemaManager _once_ and have it shared across connections?
>
> no, not at the moment, can you file a request for this in JIRA[1]
> · Can I safely use the SchemaManager after a connection has been
> returned to the pool. (e.g. instantiating Dn and other objects that
> take SchemaManager in their constructors - at a point in the application
> where communication with the LDAP server is no longer necessary - doing
> comparisons on data structures that have been cached in a session).
>
> yes, SchemaManager can be safely reused
> · I see a comment in DefaultSchemaLoader constructor: “TODO Handle
> schema loading on other LDAP servers” — how difficult would it be to
> implement parsing of OpenLDAP cn=schema,cn=config? If it's just a
> matter of banging strings around because core parsing already exists,
> maybe I could have a go at it.
>
> Studio already has the capability to parse this type of schema, perhaps we
just
need to move it to a utility class, another request please
> · Various times while parsing schemas (particularly while playing with
> SchemaToLdif), I got rather ambiguous ParserExceptions. In a debugger I
> could trace the exception to a rather detailed ANTLR exception,
> unfortunately these root causes are being discarded. Suggestion: Please
> chain exceptions!
>
> it would be helpful if you can attach the stacktrace to a new bug report
> · I feel like I'm going down a rabbit hole - all I really needed was to
> get case-insensitive equality on Dn comparison. Our server arbitrarily
> returns “o=People” and sometimes “o=people”. Making the LDAP Client API
> schema aware solves this, but so would hacking in toLowerCase in a
> bazillion places. Maybe implementing a dumbed down SchemaManager that
> returned some very naïve and static set of assumptions for common
> attributes like ‘o’, ‘ou’, ‘cn’, and ‘dc’ would work.
>
> personally I use the JarLdifSchemaLoader in cases like these
Let us know if you have any issues with this schema loader in
your application environment
[1] https://issues.apache.org/jira/browse/DIRAPI
> --
> Gerald Turner Email: gturner@unzane.com JID: gturner@unzane.com
> GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5
>
--
Kiran Ayyagari
http://keydap.com