Thank you Angela, I have a couple of questions regarding your last statement:
"if you have jcr2spi configured to use the spi2dav SPI implementation, you must make sure you have the corresponding webdav server running. spi2dav is still part of the client side. steps to go there: - deploy the JCRWebdavServerServlet (part of the jackrabbit webapp) - make sure your jcr2spi is started with spi2dav - configuration properties of spi2dav are (see repositoryStubImpl.properties): > location of the server > default workspace name" 1) When you say, "make sure your jcr2spi is started with spi2dav", where exactly is this configured? Are you talking on the servlet side? Or are you talking of whatever package I put together for the client side? 2) Related to the above question. I did find several references to the repositoryStubImpl.properties file in the main trunk and sandbox directory. Somehow I have to make sure that is read by the client package that I put together? Thanks for your feedback Julio Castillo -----Original Message----- From: Angela Schreiber [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 1:13 AM To: [email protected] Subject: Re: JCR Webdav Server -1.4.1 -looking for a client hi julio > What does it actually mean to use this servlet > (JCRWebdavServerServlet) to "remote JCR170 calls"? it means, that you have a JCR client that communicates with the persistent layer (server) using the webdav protocol. > Does it mean that the WebDav interface was "extended" to support > specific JCR calls? the JCR API maps pretty well (and surprisingly natural) to WebDAV. there were only a couple of areas that were are not covered by any of the WebDAV RFCs. This includes: - observation -> extension - clone -> unresolved - series of transient modifications (everything between 2 Session.save() calls). -> custom Lock type/scope. the mapping is described in http://jackrabbit.apache.org/JCR_Webdav_Protocol.doc > Per the online documentation a corresponding JCR client refers to the > "JCR to SPI" and "SPI to WebDAV" in the sandbox. I found the > following: a package > called: jackrabbit-jcr2spi/* on the regular release and spi2dav/* on > the sandbox. that's it. jcr2spi represents the JCR API and it requires an SPI implementation. spi2dav is one example. > Any preference on either approach? > How do I bootstrap a client? which approach? you lost me here... sorry. > On a brief look at the spi2dav files I believe this is the path to follow: > Instantiate a copy of JCR2SPIRepositoryStub which in turn will > instantiate a copy of RepositoryServiceImpl. > The starting point for my code would then start with the > JCR2SPIRepositoryStub. > I couldn't not find a starting point however with just the code in the > main trunk within the jackrabbit-jcr2spi/*. Any ideas? if you have jcr2spi configured to use the spi2dav SPI implementation, you must make sure you have the corresponding webdav server running. spi2dav is still part of the client side. steps to go there: - deploy the JCRWebdavServerServlet (by default its part of the jackrabbit webapp). - make sure your jcr2spi is started with spi2dav - configuration properties of spi2dav are (see repositoryStubImpl.properties): > location of the server > default workspace name hope that helps regards angela > Julio Castillo
