1. これは必ずしも簡単な決定ではありませんが、初心者や小さなプロジェクトにとっては、ほぼ常に WAR であると言えます。EAR を使用する主な理由は、ビジネス層を UI/Web 層から分離することです。詳細については、この質問を参照してください: Java EE アプリケーションの論理レイヤーを分離するにはどうすればよいですか?
2. 間違っているかもしれませんが、Spring の人は一般的に WAR を好むと思います。
3. JBoss (ベンダー) 固有のデプロイメント記述子は、いわゆる「管理対象オブジェクト」とセキュリティを構成するために必要です。場合によっては、Java EE 仕様でカバーされていない追加機能 (WAR の Web ルートの設定など) に使用できます。管理対象オブジェクトは通常、データ ソース (データベースへの接続) と JMS 宛先 (キューとトピック) です。
従来の Java EE アプローチでは、これらはコードからできるだけ離れた場所に作成する必要があり、これは通常、システム管理者が何らかの GUI または管理コンソールを使用してターゲット AS 内に作成することを意味します。この設定では、開発者は壁を越えて「未解決の依存関係」を持つ WAR をスローし、システム管理者 (または「デプロイヤー」) はそれらの未解決の依存関係がどうあるべきかを理解するために何日も費やします。
開発者とデプロイ担当者の間のコミュニケーションが比較的良好である場合、WAR または EAR が readme ファイルと一緒に壁を越えて投げ出される可能性があります。これにより、少なくともどのリソースが必要かについての洞察が得られます。組織によっては、開発チームは、これらの「未解決の依存関係」がどのように解決されたかについて、アクセスやフィードバックを得られない場合があります。たとえば、最大 5 つの接続を持つデータ ソースが作成された可能性がありますが、一部のコードで 10 個の並列クエリが指定されている場合、これでは不十分な場合があります。開発チームが正確なデータ ソース構成を把握していないと、実行時の問題やパフォーマンスの問題のクラスによっては、解決が比較的難しい場合があります。
これらの問題を軽減するために、一部のベンダーは、一部のアーティファクトについて、WAR または EAR に組み込まれる独自のデプロイメント記述子を使用する代わりに、開発者にこれらの「未解決の依存関係」を作成することを提案しています。単純なローカル JMS 宛先の場合は、ほとんどの場合これで終わりですが、データ ソースの場合はもう少し続きます。つまり、開発、ベータ、QA、本番などのさまざまな段階でデータ ソースを切り替えるメカニズムが必要です。さらに、ソース コードに本番パスワードを含めることはほとんどありません。
ローカルで試してみたい単純なアプリがある場合、ステージと運用パスワードは問題になりません。（大）企業に展開する場合はそうです。
Java EE 6 では、標準記述子 (web.xml、ejb-jar.xml、または application.xml) を使用してデータ ソースを定義できます。Java EE 7 では、JMS 宛先に対して同じことができます。ステージに基づいてそれらを構成する標準的な方法はありませんが、Java EE 8 がこれに対処するというかすかな希望があります (たとえばJAVAEE_SPEC-19を参照)。ベンダーは、これらの標準化された方法に普遍的に満足しているわけではありません。ベンダーの主要なドキュメントは、ほとんどの場合、独自のツールと記述子を使用してこれらのことを行う方法を拡張的に説明しています。場合によっては、それを軽視したり、本番環境での使用は推奨されていないと言って怖がらせたりすることもあります)。
4. 主に 3 への回答を参照してください。ステージ間を切り替えて本番パスワードをWAR / EARから除外する方法の問題を解決する1つのオプションは、AS内（この場合はJBoss内）で上記のデータソースの完全な定義を持つことです。このセットアップでは、すべての AS インストールが特定のサーバーに関連付けられています。データ ソースを更新、削除、または新しいものを追加する必要がある場合は、運用チーム (存在する場合) と連絡を取る必要があります。前述のように、組織によっては、これは些細なことから実質的に不可能なことまでさまざまです。
5. 開発時には、ほとんどの場合、IDE を使用して展開を行います。本番環境では、決してそれを行うことはありません。本番環境では、Ant (または Maven) でビルドし、Jenkins や Chef などを介してデプロイできます。