8:06 a.m.
Hi,
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:
dn: cn=REQUEST,dc=example,dc=com
javaClassName: com.ibm.mq.jms.MQQueue
objectClass: javaContainer
objectClass: javaObject
objectClass: javaNamingReference
javaFactory: com.ibm.mq.jms.MQQueueFactory
cn: REQUEST
javaReferenceAddress: #0#VER#6
javaReferenceAddress: #1#EXP#-2
javaReferenceAddress: #2#PRI#-2
javaReferenceAddress: #3#PER#-2
javaReferenceAddress: #4#CCS#1208
javaReferenceAddress: #5#TC#1
javaReferenceAddress: #6#ENC#273
javaReferenceAddress: #7#FIQ#1
javaReferenceAddress: #8#QU#REQUEST
javaReferenceAddress: #9#QMGR#QM
Load of this LDIF in OpenLDAP 2.3.27:
ldapadd -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"
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
And the entry is not loaded. I tried to define the entry with the
JMSAdmin tool that comes with IBM MQ, but could not load it either in
2.4.8, it worked against 2.3.27. A wireshark dump showed that the tool
received the same error as ldapadd.
I performed a "diff" on the java.schema of 2.4.8 and 2.3.27, but the schemas
are identical.
Is there any way that I could circumvent this problem?
Thanks!
8:59 a.m.
benoitde(a)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.
10:19 a.m.
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(a)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.
5645
days inactive
5645
days old
openldap-software@openldap.org
2 comments
2 participants
participants (2)
-
benoitde＠sympatico.ca -
Michael Ströder