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:
> [EMAIL PROTECTED] 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.
