You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (Created) (JIRA)" <ji...@apache.org> on 2012/03/22 18:24:22 UTC

[jira] [Created] (JCR-3271) NPE in CompiledPermissionImpl

NPE in CompiledPermissionImpl
-----------------------------

                 Key: JCR-3271
                 URL: https://issues.apache.org/jira/browse/JCR-3271
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-core
    Affects Versions: 2.2
            Reporter: Marcel Reutegger
            Priority: Minor


Every now and then I see a NullPointerException in CompiledPermissionImpl
when events are delivered from another cluster node:

java.lang.NullPointerException
	at org.apache.jackrabbit.core.security.authorization.acl.CompiledPermissionsImpl.canRead(CompiledPermissionsImpl.java:215)
	at org.apache.jackrabbit.core.security.DefaultAccessManager.canRead(DefaultAccessManager.java:251)
	at org.apache.jackrabbit.core.observation.EventConsumer.canRead(EventConsumer.java:306)
	at org.apache.jackrabbit.core.observation.EventConsumer.prepareEvents(EventConsumer.java:158)
	at org.apache.jackrabbit.core.observation.ObservationDispatcher.prepareEvents(ObservationDispatcher.java:184)
	at org.apache.jackrabbit.core.observation.EventStateCollection.prepare(EventStateCollection.java:459)
	at org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatch(DelegatingObservationDispatcher.java:126)
	at org.apache.jackrabbit.core.observation.DelegatingObservationDispatcher.dispatchEvents(DelegatingObservationDispatcher.java:99)
	at org.apache.jackrabbit.core.observation.EventStateCollection.dispatch(EventStateCollection.java:475)
	at org.apache.jackrabbit.core.state.SharedItemStateManager.externalUpdate(SharedItemStateManager.java:1526)
	at org.apache.jackrabbit.core.version.InternalVersionManagerImpl.externalUpdate(InternalVersionManagerImpl.java:633)
	at org.apache.jackrabbit.core.cluster.ClusterNode.process(ClusterNode.java:813)
	at org.apache.jackrabbit.core.cluster.ChangeLogRecord.process(ChangeLogRecord.java:498)
	at org.apache.jackrabbit.core.cluster.ClusterNode.consume(ClusterNode.java:759)
	at org.apache.jackrabbit.core.journal.AbstractJournal.doSync(AbstractJournal.java:233)
	at org.apache.jackrabbit.core.journal.AbstractJournal.internalSync(AbstractJournal.java:207)
	at org.apache.jackrabbit.core.journal.AbstractJournal.sync(AbstractJournal.java:190)
	at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java:307)
	at org.apache.jackrabbit.core.cluster.ClusterNode.run(ClusterNode.java:272)
	at java.lang.Thread.run(Thread.java:662)

The contract for DefaultAccessManager.canRead() is not quite clear on
whether it is allowed to check for read permission on an item that does
not exist, which is the case here.

AccessManager.canRead(Path itemPath, ItemId itemId) in 2.2 says it
*should* only be called for persisted items and the method would
throw a RepositoryException for NEW items, which is similar to
an item that doesn't exist anymore. In both cases it is basically
inexistent for the system session used to perform the check.

I think CompiledPermissionsImpl.canRead(Path path, ItemId itemId)
should throw a RepositoryException if it cannot resolve the given
path to an id.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira