I'm just taking a wild guess here, but are you sure it's ok to have "jcr:root" appear in the middle of some path? I've always thought the root node had to be at the actual root, but I could be wrong. I know just enough JCR to be dangerous. lol.
Best regards, Clay Ferguson [email protected] On Sun, Nov 22, 2015 at 7:32 AM, Krzysztof (JIRA) <[email protected]> wrote: > > [ > 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) >
