You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Chris (JIRA)" <ji...@apache.org> on 2014/03/27 21:25:14 UTC
[jira] [Created] (JCR-3763) Import XML fails with jackrabbit webapp
deployed
Chris created JCR-3763:
--------------------------
Summary: Import XML fails with jackrabbit webapp deployed
Key: JCR-3763
URL: https://issues.apache.org/jira/browse/JCR-3763
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-webapp, jackrabbit-webdav
Affects Versions: 2.7.5, 2.6.2
Environment: Windows 7
Reporter: Chris
Priority: Blocker
To reproduce simply deploy jackrabbit-webapp-2.6.2 or greater (haven't tested on earlier versions). I have also confirmed this issue persists with jackrabbit-webapp-2.7.5. The standalone versions do not have this issue.
With the webapp deployed, attempt to import serialized XML using sesson.importXML or workspace.importXML( ... ) fails. Note: this XML is initially serialized from existing Jackrabbit node data via session.exportXML( ... ).
When your session or workspace points to the jackrabbit-standalone configuration the import is successful and the node structure is generated on the server. When your session points to the webapp config, the process fails because:
DavLocatorFactoryImpl.getRepositoryPath() is returning the incorrect workspace path. In this example, the workspace is "default". The trace:
SEVERE: Servlet.service() for servlet [JCRWebdavServer] in context with path [/jackrabbit-webapp-2.7.5] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path: /jackrabbit-webapp-2.7.5/server/default/jcr:root/8b65d019-719f-47ec-ae2b-675c7a33048c/RTRD (workspace: /jackrabbit-webapp-2.7.5)
at org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
at org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:356)
at org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.addResponses(JcrPrivilegeReport.java:117)
at org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.init(JcrPrivilegeReport.java:102)
at org.apache.jackrabbit.webdav.version.report.ReportType.createReport(ReportType.java:72)
at org.apache.jackrabbit.webdav.jcr.AbstractResource.getReport(AbstractResource.java:487)
at org.apache.jackrabbit.webdav.jcr.WorkspaceResourceImpl.getReport(WorkspaceResourceImpl.java:84)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doReport(AbstractWebdavServlet.java:1096)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:402)
at org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:291)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: [Created] (JCR-3763) Import XML fails with jackrabbit webapp deployed
Posted by Shankar Pednekar <sh...@loudcloudsystems.com>.
Chris (JIRA <jira <at> apache.org> writes:
>
> Chris created JCR-3763:
> --------------------------
>
> Summary: Import XML fails with jackrabbit webapp deployed
> Key: JCR-3763
> URL: https://issues.apache.org/jira/browse/JCR-3763
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-webapp, jackrabbit-webdav
> Affects Versions: 2.7.5, 2.6.2
> Environment: Windows 7
> Reporter: Chris
> Priority: Blocker
>
> To reproduce simply deploy jackrabbit-webapp-2.6.2 or greater (haven't
tested on earlier versions). I
> have also confirmed this issue persists with jackrabbit-webapp-2.7.5.
The standalone versions do not
> have this issue.
>
> With the webapp deployed, attempt to import serialized XML using
sesson.importXML or
> workspace.importXML( ... ) fails. Note: this XML is initially
serialized from existing Jackrabbit node
> data via session.exportXML( ... ).
>
> When your session or workspace points to the jackrabbit-standalone
configuration the import is
> successful and the node structure is generated on the server. When your
session points to the webapp
> config, the process fails because:
>
> DavLocatorFactoryImpl.getRepositoryPath() is returning the incorrect
workspace path. In this
> example, the workspace is "default". The trace:
>
> SEVERE: Servlet.service() for servlet [JCRWebdavServer] in context with
path
> [/jackrabbit-webapp-2.7.5] threw exception
> java.lang.IllegalArgumentException: Unexpected format of resource path:
> /jackrabbit-webapp-2.7.5/server/default/jcr:root/8b65d019-719f-47ec-ae2b-
675c7a33048c/RTRD
> (workspace: /jackrabbit-webapp-2.7.5)
> at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(Dav
LocatorFactoryImpl.java:65)
> at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.g
etRepositoryPath(AbstractLocatorFactory.java:356)
> at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.addRespon
ses(JcrPrivilegeReport.java:117)
> at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.init(JcrP
rivilegeReport.java:102)
> at
org.apache.jackrabbit.webdav.version.report.ReportType.createReport(ReportTy
pe.java:72)
> at
org.apache.jackrabbit.webdav.jcr.AbstractResource.getReport(AbstractResource
.java:487)
> at
org.apache.jackrabbit.webdav.jcr.WorkspaceResourceImpl.getReport(WorkspaceRe
sourceImpl.java:84)
> at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doReport(AbstractW
ebdavServlet.java:1096)
> at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWe
bdavServlet.java:402)
> at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWe
bdavServlet.java:291)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:305)
> at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:210)
> at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:222)
> at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:123)
> at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase
.java:502)
> at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171
)
> at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:118)
> at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Proce
ssor.java:1023)
> at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstrac
tProtocol.java:589)
> at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:
312)
> at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:886)
> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
08)
> at java.lang.Thread.run(Thread.java:662)
>
> --
> This message was sent by Atlassian JIRA
> (v6.2#6252)
>
>
The issue is with following piece of code
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport
Element hrefElem = info.getContentElement(DavConstants.XML_HREF,
DavConstants.NAMESPACE);
String href = DomUtil.getTextTrim(hrefElem);
href = obtainAbsolutePathFromUri(href);
This href refers to absolute uri and contains webapp name eg:jackrabbit
So when
resourceLoc.getFactory().createResourceLocator(resourceLoc.getPrefix(),
href) is called, the code in
AbstractLocatorFactory.createResourceLocator(String prefix, String href) is
unable to extract workspace path due to webapp name. Hence to fix this
following piece of code needs to be added in
AbstractLocatorFactory.createResourceLocator(String prefix, String href){
method ---
if (pathPrefix != null && pathPrefix.length() > 0) {
if (!b.toString().endsWith(pathPrefix)) {
b.append(pathPrefix);
}
if (href.startsWith(pathPrefix)) {
href = href.substring(pathPrefix.length());
}
/*Added new code start*/
if(href.contains(pathPrefix)){
href =
href.substring(href.indexOf(pathPrefix)+pathPrefix.length());
}
/*Added new code end*/
}
This fixes the issue