Hi Jerome, you can easily provide a file system view of the repository through the WebDAV interface. This way you will store everything inside JCR, your old application will access the files through the WebDAV interface (you can mount a webdav repository as a file system in all modern OS) and the new application can leverage all JCR API features.
When installing the jackrabbit-webapp.war you will already have WebDAV contained. The standard WebDAV view only presents nodes of type nt:folder and nt:file, but you can extend that. See also http://jackrabbit.apache.org/jackrabbit-web-application.html http://jackrabbit.apache.org/jackrabbit-jcr-server.html http://jackrabbit.apache.org/jackrabbit-webdav-library.html http://wiki.apache.org/jackrabbit/WebDAV and search the mailing list for WebDAV (and "IOHandler" on how to customize the WebDAV view). Regards, Alex On Thu, Jul 3, 2008 at 7:49 PM, Jerome Banks <[EMAIL PROTECTED]> wrote: > Thomas, > Let me explain the use case a little more. You might think that it > isn't what jackrabbit is intended for, but I can imagine a lot of users > having similar requirements. > > Basically, we have an application which accesses files from a > filesystem. This application is basically legacy, and cannot be altered to > access files through jackrabbit. (At least no time soon) What we would like > is to be able to store binary files in a JCR repository, and have it > immediately accessible from the legacy application (without having to worry > about copying files and keeping JCR and the legacy filesystem in sync > somehow). We want to leverage Jackrabbit to store metadata, and have things > like queries, indexing, etc. Using a custom DataStore, we can keep it on > the remote filesystem, so that it accessible from the legacy app. However, > we have no way of communicating to our legacy app where a particular item is > on the filesystem, where a particular item is, because we can't translate > between a Property, and the associated DataIdentifier on the DataStore. > > I think the basic requirement is to have the notion of a "DataStore", > which is a custom or legacy method of storing binary data, but isn't a full > content repository. It doesn't really make sense to implement a fullblown > SPI, because all we're doing is "storing data". There are cases, however, > where we have a "leaky abstraction", and some part of the application needs > to know exactly where in the DataStore a particular item is being stored. I > guess this is somewhat different from the current notion of "DataStore", > which is a "optimization" tightly associated with BundlePersistenceManagers. > > > My current approach is to implement a custom PersistenceManager which > delegates to another PersistenceManager implementation, but intercepts > certain binary properties. It then would store the binary property in the > DataStore, and store the DataIdentifier as a generated pseudo-property in > the delegated PM. My question was just if there was an easier way; if the > delegated PM was known to be a BundlePersistenceManager, could we look up > the DataIdentifier directly from a given Property. I guess not. > > -- jerome > > On Wed, Jul 2, 2008 at 11:01 AM, Thomas Müller <[EMAIL PROTECTED]> > wrote: > >> Hi, >> >> Could you please explain what is the use case, that means why you want >> to do that? >> >> > I've gotten a custom DataStore implemented with the >> > BundleDBPersistenceManager >> >> I am not sure if I understand - you wrote an adapter / wrapper package >> that implements the DataStore interface and can use any >> BundleDBPersistenceManager? This sounds very interesting. Do you plan >> to provide the source code for that? >> >> > some part of my application needs to access the DataIdentifier associated >> > with storing a particular binary property. >> >> Currently it works like this: when storing a binary property, >> Jackrabbit first checks if the binary property is small (shorter than >> some number of bytes, lets say 1 KB). If shorter, the data is stored. >> If larger, then the binary is stored in the data store, and the unique >> hash value is stored. The DataIdentifier is this hash value. So you >> already have it. >> >> > Basically, if I have a binary Property from a Node, can I look up the >> > identifier based on the Property's UUID? >> >> Properties are not and have no UUID. The hash value is not really a >> UUID (it looks like one but it is not). >> >> > The BundlePersistenceManager has to >> > keep these stored somewhere, right? >> >> The hash values are persisted in the persistence manager. But I'm not >> sure if this is the question. The BundlePersistenceManager persists >> all data (it should ;-) >> >> Regards, >> Thomas >> > -- Alexander Klimetschek [EMAIL PROTECTED]
