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.