[
https://issues.apache.org/jira/browse/DIRSERVER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713546#action_12713546
]
Emmanuel Lecharny commented on DIRSERVER-1357:
----------------------------------------------
First, the server handle operations done on an alias without a referenced
object. It just throws some NamingException (well, it's not that perfect, as we
don't generate the resultCode atm. I'm fixing it).
Now, all the mess is due to the fact that we have an index for alias, speeding
up the retrieval of the referenced entry. Ie, we have an Alias->Entry index.
IMO, this is a waste. We already have a Alias->DN index, as the ObjectClass is
already indexed, so we immediately know that an entry is an alias (as it has
the Alias ObjectClass). Then we just have to get the aliasObjectName
attributeType, which is a DN, and a lookup for this DN will returns the entry,
or nothing if the entry does not exist.
At the end of the day, I think that this issue can vanish if we remove the
Alias index. This won't cause a lot of perfomance problem, as we just do an
indirection to retrieve the entry. Any other solution is cumbersome, complex,
and error prone.
last, not least, there are some other things we have to check : RFC 4512, chap.
2.6 says that an alias *must* not have subordinates. I'm not sure this is
tested...
> NullPointerException when deleting alias
> ----------------------------------------
>
> Key: DIRSERVER-1357
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1357
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.5, 1.5.4
> Reporter: Stefan Seelmann
> Fix For: 1.5.5
>
> Attachments: DIRSERVER_1357.java
>
>
> There is a NPE when deleting an alias entry is some special case. Here is a
> example DIT:
> ou=system
> |--ou=sales
> | |--cn=foo <--real entry
> |--ou=engineering
> |--cn=foo <--alias, pointing to the real entry
> When I first delete the real entry and afterwards the alias the server throws
> an exception, when it cleans the oneAliasIdx and subAliasIdx in the
> JdbmStore. Note, the exception does not occur if the real entry and alias are
> direct descendants of the context entry, because in that case the oneAliasIdx
> and subAliasIdx are not used.
> java.lang.NullPointerException
> at
> org.apache.directory.server.core.partition.impl.btree.LongComparator.compare(LongComparator.java:45)
> at
> org.apache.directory.server.core.partition.impl.btree.LongComparator.compare(LongComparator.java:1)
> at
> org.apache.directory.server.core.avltree.AvlTree.find(AvlTree.java:661)
> at
> org.apache.directory.server.core.avltree.AvlTree.remove(AvlTree.java:217)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmTable.remove(JdbmTable.java:662)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.drop(JdbmIndex.java:468)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmStore.dropAliasIndices(JdbmStore.java:822)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmStore.delete(JdbmStore.java:1098)
> at
> org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.delete(JdbmPartition.java:487)
> at
> org.apache.directory.server.core.partition.impl.btree.BTreePartition.delete(BTreePartition.java:217)
> at
> org.apache.directory.server.core.partition.DefaultPartitionNexus.delete(DefaultPartitionNexus.java:824)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
