ファイルシステムを使用してスクリプトと構成データを保存する、OSGi ベースのサーバー側アプリケーションがあります。
いずれ、そのアプリケーションを「クラウド」に移行したいと考えていますが、ファイル システム アクセスへの現在の依存関係ではうまく機能しません。
私がやりたいのは、このアプリケーションに JCR レイヤーを挿入することです。これにより、現在の状況 (ローカル ファイル システム上の通常のファイル) でも機能しますが、クラウドの状況への道が開かれます。
modeshape でファイル コネクタを見つけましたが、OSGi とのかなり深刻な非互換性に遭遇しました。これは修正されていません。その上、ModeShape は大量の依存関係 (約 6 MB だと思います) を取り込みますが、これは私にとっては問題です。
そのため、自分の JCR 実装のハックを開始する以外に選択肢はありません。
何か案は？
JCR を直接使用することはありませんが、Apache Sling ResourceProvider メカニズムを使用すると、後でファイルシステムから別のシステムに簡単に移行できます。また、Sling は 100% OSGi に基づいているため、OSGi フレンドリーです。
今すぐ Sling の Filesystem リソース プロバイダー ( http://sling.apache.org/site/accessing-filesystem-resources-extensionsfsresource.html ) を使用して開始し、後で必要に応じて独自のカスタム ResourceProvider に移動できます。
ファイルシステム プロバイダーのソース コードはhttps://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/fsresourceにあります。これは、独自の ResourceProvider を作成するための例として使用できる非常に単純なコードです。
カスタム システムの場合、それを機能させるために必要な Sling バンドルの数が問題になります。不要なバンドルですが、ResourceProvider メカニズムが動作できるように最小限に減らすこともできます。
また、Apache Commons VFS2 を使用することもできます。たとえば、JCR コネクタがあり、webdav または JDBC テーブルを使用することもできます。私はこれを、共有 JDBC テーブルの上のアトミック (git のような) ツリーの上にある商用プロジェクトで使用します。