継承したプロジェクトのアーキテクチャをリファクタリングできるかどうかを確認しようとしており、可能な解決策として Apache Karaf に興味があります。
現在、すべての (非営利) クライアントに対して実行可能な JAR を構築し、JAR をさまざまな時間に実行するように cron を作成しています。各「クライアント JAR」は、それらの中でいくつかの「共通」JAR を使用し、その内部にクライアント固有のロジックを含みます。全体で、数百のクライアント JAR と約 12 の一般的な JAR があります。
このアーキテクチャには多くの問題があります。
- コモンズ JAR は単にライブラリであることを意図しているため、クライアント JAR を実行するための共通プラットフォームはありません。それらの多くは Apache Camel を使用し、それらの JAR に対してローカルなルートを使用しており、すべての JAR で大量の Camel コードが複製されています。すべてのクライアント JAR が同じ Camel ルートを共有できるソリューションがあると便利です。
- 各クライアント JAR をいつ実行するかのビジネス ロジックを cron の手に委ねますが、これは Java であるため、すべての JAR をいつ実行するかを制御するマスター Quartz "Scheduler" を使用したいと思います。
- Commons JAR の 1 つに依存関係を追加する必要があるたびに、すべてのクライアント JAR のすべての crontab エントリを確認し、classpath 引数を変更して追加の依存関係を取得する必要があります。
- リストは延々と続きます...
- 実行可能なクライアント JAR を cron 化するという考えは、それらが同じコンテナーにデプロイされた場合にはるかにまとまりのある動作をする可能性があるのに好きではありません。
基本的に、次のようなソリューションが必要です。
- システムの残りの部分を中断することなく、クライアント JAR の新しいバージョンをいつでもデプロイ/アンデプロイおよび再デプロイできる
- コモンズ JAR を展開/展開解除して、開始される新しいクライアント JAR がコモンズ JAR の新しいバージョンを取得するようにします。
- 各クライアント JAR を 1 週間の異なる時間に実行するように cron/スケジュールできる Quartz Scheduler (WAR または JAR) を展開/展開解除できます
- クライアント JAR のそれぞれが同じキューとルートを使用できるように、メッセージ ブローカーとおそらく Camel や Mule などの ESB を展開/展開解除できます。
- 単一のロギング JAR (log4j、commons logging など) と単一の JPA 実装 JAR (Hibernate、MyBatis など) をデプロイ/アンデプロイし、すべてのクライアント JAR で普遍的に使用/使用可能にすることができます。
上記のすべてをカラフで達成できますか? そうでない場合、選択肢はありますか (Felix、Equinox など)? それとも私は夢を追っていますか？問題のドメインを考えると、現在のソリューションに固執する必要がある注意事項や理由はありますか? 前もって感謝します！
注意: OSGiの代わりにEJB3 が私にとって良い解決策であると誰かが考えている場合、私はあなたの議論を聞くことにオープンです。おそらくそのような解決策を承認します。