[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690223#comment-13690223 ] Julian Reschke commented on JCR-3228: - Workaround: set JCRWebdavServerServlet.INIT_PARAM_CREATE_ABSOLUTE_URI to "false" -- this seems to fix the issue. > 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.13, 2.4.4, 2.6.2, 2.7.1 >Reporter: Timothee Maret >Assignee: Julian Reschke >Priority: Minor > > 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 : when running on any > other port. -- This message is automatically gene
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223661#comment-13223661 ] Julian Reschke commented on JCR-3228: - This is a bit harder than I hoped: the canonical way to normalize the port number would be to use java.net.URI to parse and reconstruct, but that has nasty effects on escaping ":" in path components. > 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 >Assignee: Julian Reschke > > 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 : when running on any > other port.
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223357#comment-13223357 ] Julian Reschke commented on JCR-3228: - This can be reproduced by setting the port to 80 in org.apache.jackrabbit.jcr2dav.RepositoryStubImpl, then running the integration tests. > 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 >Assignee: Julian Reschke > > 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 : when running on any > other port. -- This message is automatically generated by JIRA. If you thi
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213485#comment-13213485 ] Timothee Maret commented on JCR-3228: - The Webdav spec does not mandate the port number in the multi-status responses either.. thus I believe it is up to the client to deal with this case. A workaround to this issue is to avoid specifying the default port when connecting. This mean, one could use exclusively the url: http://server/mount/point instead of http://server:80/mount/point > 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 p
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[ https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13210096#comment-13210096 ] Felix Meschberger commented on JCR-3228: The spec does not mandate to include the port number in the Host header. So it is not appropriate to expect the client to include the port number. So the server must cope with this situation appropriately, namely re-insert the default port number if required. > 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 : when ru
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[
https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209923#comment-13209923
]
Timothee Maret commented on JCR-3228:
-
Actually the port is striped by the commons-httpclient library, as shown by
this snippet [0].
As the host port is required by the current Webdav implementation (eg. [1]), a
solution could be to
explicitely set the host header through the virtual host parameter, if and only
if the port matches the protocol default port.
[0] org.apache.commons.httpclient.HttpMethodBase#addHostRequestHeader
protected void addHostRequestHeader(HttpState state, HttpConnection conn)
throws IOException, HttpException {
...
String host = this.params.getVirtualHost();
if (host != null) {
LOG.debug("Using virtual host name: " + host);
} else {
host = conn.getHost();
}
int port = conn.getPort();
...
//appends the port only if not using the default port for the protocol
if (conn.getProtocol().getDefaultPort() != port) {
host += (":" + port);
}
setRequestHeader("Host", host);
}
[1] org.apache.jackrabbit.spi2dav.IdURICache#add(String uri, ItemId itemId)
> 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
[jira] [Commented] (JCR-3228) WebDav/DavEx remoting throws workspace missmatch exceptions when running on port 80.
[
https://issues.apache.org/jira/browse/JCR-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202288#comment-13202288
]
Julian Reschke commented on JCR-3228:
-
maybe caused by the authority part of URI sometimes normalized (":80" removed)
or not?
> 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 : 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.apach
