[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem loading LDIF data in openldap 2.4.8



Hi Michael,

Here are the schema definitions for the three objectClass referenced in
the LDIF:

	objectclass ( 1.3.6.1.4.1.42.2.27.4.2.1
		NAME 'javaContainer'
		DESC 'Container for a Java object'
		SUP top
		STRUCTURAL
		MUST cn )

	objectclass ( 1.3.6.1.4.1.42.2.27.4.2.4
		NAME 'javaObject'
		DESC 'Java object representation'
		SUP top
		ABSTRACT
		MUST javaClassName
		MAY ( javaClassNames $ javaCodebase $
			javaDoc $ description ) )

	objectclass ( 1.3.6.1.4.1.42.2.27.4.2.7
		NAME 'javaNamingReference'
		DESC 'JNDI reference'
		SUP javaObject
		AUXILIARY
		MAY ( javaReferenceAddress $ javaFactory ) )


Here's section 2.4.1 of the RFC you mentioned:

	2.4.1.  Abstract Object Classes

	   An abstract object class, as the name implies, provides a base of
	   characteristics from which other object classes can be defined to
	   inherit from.  An entry cannot belong to an abstract object class
	   unless it belongs to a structural or auxiliary class that inherits
	   from that abstract class.

Because javaNamingReference inherit from javaObject, it should be OK for
the entry to belong to javaNamingReference (auxiliary class, inherited
from javaObject), javaObject (abstract, but OK, because javaNamingReference is
listed) and javaContainer (structural class). You're right
that it is redundant to list javaObject in the LDIF, but since it's OK,
and most (if not all?) java tools list these 3 classes, I was curious to
find if there was some way to make OpenLDAP 2.4.8 accept it. In the
meantime I'll have to stick with 2.3.27, even though the mirror
replication mode would have been nice ;)

Thanks!


On Wed, Apr 16, 2008 at 05:59:05PM +0200, Michael Str?der wrote:
> benoitde@sympatico.ca wrote:
> >
> >I tried to load a slapcat dump from OpenLDAP 2.3.27 into OpenLDAP 2.4.8,
> >and had problems with java entries. I narrowed down the problem with
> >this simple test case:
> >
> >LDIF:
> >[..]
> >	objectClass: javaContainer
> >	objectClass: javaObject
> >	objectClass: javaNamingReference
> >[..]
> >Works, but in OpenLDAP 2.4.8:
> >
> >	ldapadd -h sdco1cdba -p 1389 -D"cn=Manager,dc=example,dc=com" -W -x 
> >	-f /tmp/bug.ldif
> >	Enter LDAP Password:
> >	adding new entry "cn=REQUEST,dc=example,dc=com"
> >	ldap_add: Object class violation (65)
> >		additional info: instanstantiation of abstract objectClass 
> >		'javaObject' not allowed
> 
> I'd guess 2.4.x is more strict regarding ABSTRACT object classes which 
> are not meant for being directly used in entries (see section 2.4.1 of 
> RFC 4512). I don't know this schema. Could you please post the schema 
> definition of the 'javaObject' object class and its derived object classes?
> 
> >Is there any way that I could circumvent this problem?
> 
> Probably just remove the lines with
> objectClass: javaObject
> from your LDIF.
> 
> But make sure that the other object classes needed (at least one 
> STRUCTURAL object class) are derived from it.
> 
> Ciao, Michael.