6

deps ディレクトリが別のアプリケーションに依存している Erlang アプリケーションがあります。

私が理解していることから、私は次のいずれかを行うことができます。

a) application:start(some_other_app) を呼び出して、インクルード アプリケーションから従属アプリケーションを開始します。これにより、アプリケーションが開始され、Observer 内でスタンドアロンで実行されていることが示されます。

b) {included_applications, [some_other_app]} を使用して依存アプリケーションを .app ファイルに含めて、アプリケーションが読み込まれ、開始されないようにしてから、含まれているアプリケーションを自分の最上位スーパーバイザーから開始します。これにより、含まれているアプリケーションが再び起動し、Observer の自分の監視階層の下で実行されていることが示されます。

私の質問は、いつどちらのアプローチを使用する必要があるかということです。オプション「a」を使用し、依存するアプリケーションが終了した場合、それは再起動されますか、それとも依存関係が監視されるようにアプローチ「b」を使用する必要がありますか?

余談ですが、依存関係のパッケージ化と管理には Rebar を使用しています。

ありがとう、

アンディ。

4

3 に答える 3

4

おそらく、a) も b) も行うべきではありません

Learn You Some Erlangから

章を見てください:含まれるアプリケーション

含まれているアプリケーションを使用しないことがますます推奨される理由は単純です。コードの再利用が著しく制限されているからです。このように考えてください。私たちは ppool のアーキテクチャに多くの時間を費やし、誰もが ppool を使用できるようにし、独自のプールを取得して、好きなことを自由に行えるようにしました。含まれているアプリケーションにプッシュすると、この VM 上の他のアプリケーションに含めることができなくなります。erlcount が終了すると、ppool も一緒に削除され、必要なサードパーティ アプリケーションの作業が台無しになります。 ppool を使用します。

これらの理由から、含まれるアプリケーションは通常、多くの Erlang プログラマーのツールボックスから除外されています。次の章で説明するように、リリースは基本的に、より一般的な方法で同じこと (およびそれ以上) を行うのに役立ちます。

Release is the Wordの章では、いくつかのアプリケーションがどのようにリリースにバンドルされ、どのように開始されるかについて読むことができます。

于 2012-07-05T18:17:25.117 に答える
1

アプリケーション記述子で依存関係を宣言するのが最善の方法であるため、ほとんどのシナリオでオプション B を使用する必要があります。

アプリケーションコントローラーは、アプリケーションを開始する前に、すべての依存関係が存在し、(順番に) 開始されていることを確認し、それらがエラーで終了した場合はアプリを失敗させます。また、アプリケーション コントローラーは、必要に応じてすべてをシャットダウンします。

それ以外に、オプション A を選択した場合、application:start/1 でアプリケーションを起動すると、デフォルトで一時的なアプリケーションが取得されるので、application:start/2 を使用して、永続的なアトムを 2 番目の引数として渡す必要があります。

編集:アプリケーション記述子に依存関係があることも可視性に役立ちます。ソースコードをスキャンせずに deps を簡単に知ることができます。

于 2012-06-21T15:36:41.700 に答える
0

同様の質問がありました。どのように依存関係を erlang プロジェクトに含め、その後どのように解放しますか?

さまざまな友人や erlang メーリング リストの助けを借りて...いくつかのドキュメントを読み直し、試行錯誤を繰り返した結果、いくつかのことがわかりました。長いので、要点を確認してください。

https://gist.github.com/3728780

-トッド

于 2012-09-16T02:48:42.503 に答える