私たちのJavaデスクトップアプリケーションは、ユーザーが編集したいくつかのテキストファイルを管理しています。アプリケーションデータパーシスタンスフレームワーク/ライブラリ？
現在、これらのファイルは、社内のJavaコードを使用してファイルシステムに保存されます。私たちはこれから離れて、代わりに既存のフレームワーク/ライブラリ（好ましくはオープンソース）を使用したいと思います。実行時に実際の永続的なストレージを構成する可能性があることがうれしいです： "ファイルシステム"対 "db"。
JCRの実装（JackRabbitなど）以外の解決方法はありますか？ユースケースにJCRを使用する際のフィードバックやアドバイスはありますか？
Thx。
JCRリポジトリの利点の一つは、それがデータが永続化されている方法からアプリケーションを抽象化していることであるが、それでも階層的な組織、クエリ、検索、イベントを提供、など
ModeShapeはその申し出JCRの実装ですデータがどのように格納されるかに大きな柔軟性をもたらします。そのconnectors（federation経由）の組み合わせで、SVNで、data grid（例えば、Infinispan）で、（多くのDBMSがサポートされています）relational databaseで、ファイルシステム（twochoices）にアクセスおよび/またはコンテンツの保存を許可しますか、さらにin-memory（小さく、重要度の低い用途向け）。 ModeShapeはfluent programmatic APIを使用して設定することができますが、エンジンを起動すると本当にコネクタを変更することはできません。
（フル開示：私はプロジェクトリーダーです。）ModeShapeとアクセスにJCRのAPIを使用することができ、ファイルシステムコネクタのアプリケーションで、ファイルシステム上のファイルを保存するユースケースのためにそう
（ の既存の構造のファイルとフォルダ）を使用して、他のアプリケーションがファイルシステムを介して同じファイルとフォルダにアクセスできるようにします。このコネクタを使用すると、アプリケーションはファイルノードとフォルダノード上に任意でstore extra propertiesを追加できますが、ファイルノードとフォルダノードのみを作成することに制限されます。
また、ModeShapeのディスクコネクタを使用すると、ファイル、フォルダ、その他のコンテンツを作成してディスクに保存することができます。このコネクタは、ファイルシステムのコネクタよりもはるかに優れています。なぜなら、任意のコンテンツ（それは非常に高速です）を格納できるからです。また、リポジトリの内容はファイルシステム上のファイルとして保持されますが、リポジトリの構成方法とは異なる構造を使用します。 IOWでは、ディスクコネクタは実際には設計されていないため、他のアプリケーションがファイルシステムを使ってリポジトリに保存したファイルにアクセスすることができます。後者が重要ではなく、ファイルシステムにコンテンツを管理して格納する方法を探しているだけの場合は、ディスクコネクタが優れた選択肢になります。