WebDav/DavEx remoting throws workspace missmatch exceptions when running on
port 80.
-------------------------------------------------------------------------------------
Key: JCR-3228
URL: https://issues.apache.org/jira/browse/JCR-3228
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-spi2dav, jackrabbit-webdav
Affects Versions: 2.2.9
Reporter: Timothee Maret
When running on port 80, the webdav remoting shows unexpected behavior such as
listing incomplete folder content.
Moreover the following exception is thrown:
The exception I get: java.lang.IllegalArgumentException: Workspace missmatch.
[org.apache.jackrabbit.spi2dav.IdURICache.add(IdURICache.java:60),
org.apache.jackrabbit.spi2dav.URIResolverImpl.getItemUri(URIResolverImpl.java:129),
org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.getItemUri(RepositoryServiceImpl.java:391),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:149),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getPath(RepositoryServiceImpl.java:138),
org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.getItemInfos(RepositoryServiceImpl.java:265),
org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:93),
org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:97),
org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.doResolve(NodeEntryImpl.java:990),
org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.resolve(HierarchyEntryImpl.java:133),
org.apache.jackrabbit.jcr2spi.hierarchy.HierarchyEntryImpl.getItemState(HierarchyEntryImpl.java:252),
org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getItemState(NodeEntryImpl.java:71),
org.apache.jackrabbit.jcr2spi.ItemManagerImpl.getItem(ItemManagerImpl.java:199),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.prefetchNext(LazyItemIterator.java:138),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.next(LazyItemIterator.java:251),
org.apache.jackrabbit.jcr2spi.LazyItemIterator.nextNode(LazyItemIterator.java:154),
com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:121),
com.adobe.drive.connector.adep.GetChildrenHandler.execute(GetChildrenHandler.java:43),
com.adobe.drive.model.internal.synchronization.AssetSynchronizer.execute(AssetSynchronizer.java:432),
com.adobe.drive.model.internal.synchronization.AssetSynchronizer.synchronizeStructure(AssetSynchronizer.java:352),
com.adobe.drive.internal.data.manager.DataManager.getChildren(DataManager.java:2602),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:98),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren$1.call(GetChildren.java:73),
com.adobe.drive.model.context.Context.run(Context.java:88),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:126),
com.adobe.drive.internal.biz.versioncue.service.call.GetChildren.executeItem(GetChildren.java:50),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:125),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall$1.run(VersionCueCall.java:119),
com.adobe.drive.data.internal.persistence.PersistenceRunner.run(PersistenceRunner.java:119),
com.adobe.drive.internal.biz.versioncue.service.call.VersionCueCall.execute(VersionCueCall.java:134),
com.adobe.drive.internal.biz.versioncue.service.VersionCueService.getChildren(VersionCueService.java:269),
com.adobe.drive.ncomm.versioncue.GetChildren.handle(GetChildren.java:59),
com.adobe.drive.ncomm.versioncue.VersionCueRequestHandler$1.run(VersionCueRequestHandler.java:185),
com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:270),
com.adobe.drive.core.internal.jobs.JobHandler$JobWrapper.run(JobHandler.java:286),
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886),
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908),
java.lang.Thread.run(Thread.java:680)]
I have tracked this issue and actually the HTTP "Host" header which is used to
identify the webdav server does not contain the port (only the host) when
running on port 80, whereas it contains the <host>:<port> when running on any
other port.
--
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
