Our Java desktop application is managing several text files as edited by the users.
Currently, those files are saved into the file system using in-house Java code. We'd like to move away from this and use an existing framework/library instead (preferably open-source); would be nice to have the possibility to configure at runtime the actual persistent storage : "file-system" vs. "db".
Apart from a JCR implementation (e.g., JackRabbit) is there any other possible solution? Any feedback/advice on using JCR for our use-case?
Thx.
One of the benefits of a JCR repository is that it abstracts the application from way the data is persisted, yet still provides hierarchical organization, query, search, events, etc.
ModeShape is a JCR implementation that offers a great deal of flexibility in how the data is stored. Its connectors allow access and/or storage of content on the file system (two choices), in a relational database (many DBMSes are supported), in a data grid (e.g., Infinispan), in SVN, in a combination (via federation), or even in-memory (for smaller, less critical uses). ModeShape can be configured using a fluent programmatic API, but once you start the engine you really can't change the connectors.
(Full disclosure: I'm the project lead.)
So for your use case of storing files on the file system, with ModeShape and its file system connector your application could use the JCR API to access (and manipulate) an existing structure of files and folders, all the while letting other applications still access the same files and folders via the file system. With this connector, your application can optionally store extra properties on the file and folder nodes, but you're limited to creating only file and folder nodes.
Another option for your use case would be to use ModeShape's disk connector, which allows your application to create files, folders and other content and store the information on disk. This connector is far more capable than the file system connector, because it can store any content (plus it's very fast). It also persists repository content as files on the file system, but it uses a different structure than how the repository is organized. IOW, the disk connector is not really designed so that other applications can use the file system to access the files you've stored in the repository. If the latter is not important and you are just looking for a way of managing and storing content on a file system, then the disk connector would be an excellent choice.