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!