[
https://issues.apache.org/jira/browse/JCR-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020993#comment-15020993
]
Krzysztof edited comment on JCR-3763 at 11/22/15 1:31 PM:
----------------------------------------------------------
Hi [~pednekar],
I have encountered exactly the same issue when trying to set an ACL entry for
a sample, test node in my application I am using to evaluate jackrabbits'
suitability for my solution (I am calling the web-app as a remote repository
from withing my app). I have tried on jackrabbit web-app 2.10.1 and the newest
2.11.3 but I am still getting the:
javax.jcr.RepositoryException: Internal Server Error,
which on the server side (tomcat) is represented by:
1. In console: DavLocatorFactoryImpl.java:64 Unexpected format of resource
path.
2. In logs - more detailed:
22-Nov-2015 14:23:35.226 SEVERE [http-apr-8080-exec-5]
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for
servlet [JCRWebdavServer] in context with path
[/jackrabbit-webapp-2.11.3-SNAPSHOT] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path:
/jackrabbit-webapp-2.11.3-SNAPSHOT/server/default/jcr:root/folder/customResource
(workspace: /jackrabbit-webapp-2.11.3-SNAPSHOT)
at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:356)
I am calling the server(web-app) setting the ACL for a node
"/folder/customResource" (absolutePath used all over in my code). But as you
can see the workspace recognized on web-app side is
"jackrabbite-webapp-2.11.3-SNAPHOST) which is obviously wrong.
You have provided us above with some solution to fix this in the code of
web-app but I wanted to use jackrabbit in "as if" form and I would rather avoid
to introducing my own changes.
I am just considering the following:
1. Is there any other way to fix this (e.g. via configurations files)?
2. Is this a bug at all (as mentioned earlier by Chris, it works with
standalone instance).
3. Is there a chance to the have the fix in jackrabbit's trunk? (I checked on
2.11.3, it is still throwing the exception).
I would be greatful for any guidance or help on that. Thank you.
was (Author: krzysztof.lembicz):
Hi [~pednekar],
I have encountered exactly the same issue when trying to set an ACL entry for
a sample, test node in my application I am using to evaluate jackrabbits'
suitability for my solution (I am calling the web-app as a remote repository
from withing my app). I have tried on jackrabbit web-app 2.10.1 and the newest
2.11.3 but I am still getting the:
javax.jcr.RepositoryException: Internal Server Error,
which on the server side (tomcat) is represented by:
1. In console: DavLocatorFactoryImpl.java:64 Unexpected format of resource
path.
2. In logs - more detailed:
22-Nov-2015 14:23:35.226 SEVERE [http-apr-8080-exec-5]
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for
servlet [JCRWebdavServer] in context with path
[/jackrabbit-webapp-2.11.3-SNAPSHOT] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path:
/jackrabbit-webapp-2.11.3-SNAPSHOT/server/default/jcr:root/folder/customResource
(workspace: /jackrabbit-webapp-2.11.3-SNAPSHOT)
at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:356)
I am calling the server(web-app) setting the ACL for a node
"/folder/customResource" (absolutePath used all over in my code). But as you
can see the workspace recognized on web-app side is
"jackrabbite-webapp-2.11.3-SNAPHOST) which is obviously wrong.
You have provided us above with some solution to fix this in the code of
web-app but I wanted to use jackrabbit in "as if" form I would like to avoid to
introducing my own changes.
I am just considering the following:
1. Is there any other way to fix this (e.g. via configurations files)?
2. Is this a bug at all (as mentioned earlier by Chris, it works with
standalone instance).
3. Is there a chance to the have the fix in jackrabbit's trunk? (I checked on
2.11.3, it is still throwing the exception).
I would be greatful for any guidance or help on that. Thank you.
> 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.6.2, 2.7.5
> Environment: Windows 7
> Reporter: Chris
> Priority: Blocker
> Labels: DavLocatorFactory, import, jackrabbit, webapp, webdav,
> xml
> Attachments: TestEAVCoreRepository.java
>
>
> UPDATE: this seems to be very similar to the issue reported in:
> https://issues.apache.org/jira/browse/JCR-3668
> 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.exportSystem( ... ).
> 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.3.4#6332)
