現在、新しいプロジェクトを開始しています。テクノロジーを選ばなければなりません。軽いものが必要なので、EJBやSeamは必要ありません。一方、私はJPA（Hibernateまたは代替）とIceFacesでのJSFが必要です。
TomcatにデプロイされたSpring 3のそのようなスタックは良い選択だと思いますか？または、Java EE 6 Webアプリケーションの方が優れているでしょうか。申し訳ありませんが、Java EE 6は新しい技術であり、まだ十分に文書化されていません。TomcatはGlassfish 3よりも保守が簡単なようです。
あなたの意見は何ですか？何か経験はありますか？
回答:
軽いものが必要なので、EJBやSeamは必要ありません。
EJB3以降にEJBが重くなる理由を説明してもらえますか？私たちが2004年にはもういないことをご存知ですか？私はあなたの光の定義とあなたの議論を本当に読みたいと思います（そして私はいくつかの確かなことが言えると確信しているので、喜んで私の答えを更新します）。
一方、私はJPA（Hibernateまたは代替）とJSFとIceFacesが必要です。
JSF 2.0、JPA 2.0、Bean Validation、EJB 3.1 Lite、CDIなどを含むJava EE 6 Webプロファイルはこれに最適であり、GlassFish v3 Webプロファイルを使用して、Java EE 6 Webプロファイルで構築されたアプリケーションを実行できます。 。
TomcatにデプロイされたSpring 3のそのようなスタックは良い選択だと思いますか？または、Java EE 6 Webアプリケーションの方が優れているでしょうか。
ええと、私は独自のコンテナ（Spring）ではなく、独自のプラットフォーム（Java EE）でコードを実行するというアイデアが気に入っています。そして、私はJava EE 6で十分だと思います（そしてこれは、冒涜、EJB 3.1（Lite）、JPA 2.0、JSF 2.0、CDIキックアスです）。私はJSFに懐疑的でしたが、再確認しました。CDIを使用したJSF 2.0は非常に異なるため、比較することもできません。そして、もしあなたがCDIを見ていないなら、それが素晴らしいことを私に教えさせてください。
申し訳ありませんが、Java EE 6は新しい技術であり、まだ十分に文書化されていません。
Java EEは、かなりよくドキュメント化されているように見えます。これは無料のクレームのようです。そして、私を信じるかどうか、私は、 Java EEのが容易になっている間春が複雑化を見つけるために開始します。
TomcatはGlassfish 3よりも保守が簡単なようです。
何かやってみましたか？特定の問題に直面しましたか？繰り返しますが、これは無料のクレームのようです。
JavaEE6は使用していません。
ただし、JavaEEおよびEJBの以前のすべてのバージョンにひどく打ち負かされており、デジュール標準だけでなく、デファクトスタンダードとしての地位を確立するまでは信頼できません。現在、Springは事実上の標準です。
一度私をだまして、あなたに恥を。私を二度バカにして、恥をかいてください。EJBを3回だまして。
Springは専有であると主張する人もいます。JavaEE仕様のベンダー実装は、それ以上ではないにしても、同じように独自仕様であったと私は主張します。
最近、一連のJavaアプリケーションをJBossからWeblogicに移行するという大きな転換を経験しました。すべてのSpring / Hibernateアプリは、必要なライブラリがすべて組み込まれているため、修正なしで移植されました。JPA、EJB、およびJSFを使用するすべてのアプリは、移植が困難でした。アプリサーバー間でのJPA、EJB、JSFの解釈の微妙な違いにより、あらゆる種類の厄介なバグが発生し、修正に永久に時間がかかりました。JNDIネーミングのような単純なものでさえ、AppServer間で完全に異なっていました。
Springは実装です。JavaEEは仕様です。それは大きな違いです。仕様が100％気密で、ベンダーがその仕様を実装する方法にまったく余裕がない場合は、仕様を使用したいと思います。しかし、JavaEE仕様はそうではありませんでした。多分JavaEE6はもっと気密ですか？知りません。WARにパッケージ化できる数が多く、AppServerライブラリへの依存度が低いほど、アプリケーションの移植性が向上します。それが、結局のところ、私がDot-NETではなくJavaを使用する理由です。
仕様に気密性があったとしても、アプリケーションに含まれるすべてのテクノロジスタックをそれに合わせてアップグレードしなくても、appserverをアップグレードできると便利です。JBoss 4.2からJBoss 7.0にアップグレードする場合、すべてのアプリケーションに対する新しいバージョンのJSFの影響を考慮する必要があります。Spring-MVC（またはStruts）アプリケーションへの影響を考慮する必要はありません。
それは問題ではありません。Java EE 6は十分であり、そこにプロファイルがあるため、「重い」わけではありません。Webプロファイルを使用するだけです。
個人的には、春が好きです。しかし、私はJava EE 6に対する合理的な議論を使い果たしています:)
（コメントで気づかれたように、必要なコンポーネントによっては、RichFaces、ICEfaces、PrimeFaces、またはその両方を試してみてください）。
最近、私のクライアント割り当ての1つに、Spring Stackとカスタムフレームワークスタックの比較とJava EE標準の評価が含まれていました。1か月の評価とプロトタイピングの後、私は満足しているだけでなく、Java EE 6機能セットに驚かされました。2011年以降の新しい「エンタープライズ」プロジェクトアーキテクチャについては、Java EE 6とSeam 3のような潜在的な拡張機能、または今後のApache JSR299拡張プロジェクトを使用します。Java EE 6アーキテクチャは合理化されており、過去数年で進化した多くのオープンソースのアイデアの中で最も優れています。
イベント管理、コンテキストとDI、インターセプター、デコレーター、RESTful Webサービス、組み込み可能なコンテナーとの統合テスト、セキュリティなど、すぐに使える機能を検討してください。
私の結果のほとんどは、あなたが役立つと思うJava EE 6の主要な概念を説明する私のブログで公開されています。
もちろん、フレームワークを選択するための厳格なルールはありません。Java EE 6は、豊富な会話型セッション状態を必要としない、より単純な「Webサイト」には肥大化する可能性があります。GrailsまたはPlayを選択することもできます。フレームワーク。しかし、会話形式のWebアプリケーションの場合、Java EE 6が適切でない理由について、これ以上の議論はありません。
さて、しばらくしてから、スタックの経験があります：
私の結論は：
アダム・ビエンのエンタープライズJavaの未来を読んでください...明確です（Java EEのSpringとVice Versaの有無）が含まれている場合と含まれていない場合。私はいくつかの理由でSpringを選択しますが、以下はその1つです（投稿からのコメントの1つを再現しています）
「あなたが話しているJava EE 6サーバーがわかりません。Glassfish認定およびTMAX JEUSがあります。Java EE 6に準拠したバージョンのWebSphere、WebLogic、JBossなどが本番になり、実際のアプリケーションで使用できるようになるまでには、かなりの時間がかかります（数年後）。Spring 3はJava 1.5とJ2EE 1.4を必要とするだけなので、ほとんどすべての環境ですぐに使用できます。
私の意見は、他の人には言及されていないことに基づいています。つまり、私の仕事のコードは数十年（文字通り）存続する傾向があるため、メンテナンスは私たちにとって非常に重要です。独自のコードと使用するライブラリのメンテナンス。私たちが管理する独自のコードですが、私たちが使用するライブラリは、上記の数十年以上の間、他のユーザーによって管理されています。
簡単に言えば、これを実現する最良の方法は、Sun仕様のオープンソース実装を生のJVMまで使用することであると結論付けました。
オープンソースの実装のうち、Apache Jakartaはライブラリを維持することが証明されており、最近SunはGlassfish v3の高品質な実装を作成するために多くの作業を行いました。いずれにせよ、すべてのモジュールのソースも用意されているため、他のすべてが失敗した場合でも、自分で保守できます。
通常、Sunの仕様は非常に厳密であり、仕様に準拠した実装は簡単に交換できます。サーブレットコンテナをご覧ください。
この特定のケースでは、JavaServer Facesを調べることをお勧めします。これは、JavaServerがJava EE 6の一部であるため、非常に長期間にわたって利用および保守できるからです。次に、MyFaces Tomahawkを使用して、いくつかの便利な追加機能を提供することを選択しました。これは、ジャカルタプロジェクトです。
JBoss Seamやその他に問題はありません。彼らの焦点は、私たちにとって非常に重要なメンテナンスの問題に向けられていないというだけです。
Springを既に使用している場合は使用できますが、新しいプロジェクトの場合、何がポイントですか？私はJava EE 6（ejb3、jsf2.0など）を直接使用します
クライアントがFlexで問題ない場合は、それを試してください。BlazeDSまたは同様のものを使用します-mvcは使用しません。その部分（サーバーとクライアント間でのデータ交換）により多くの時間を費やす可能性がありますが、両方を完全に制御できます。
ブラウザを強制終了したい場合を除き、Vaadinを使用しないでください。さらに、ページが複雑になると、コードを回避するためにより多くの時間を費やすことになります。また、考え方を完全に変更する必要があり、標準のフロントエンド開発について知っているものはすべて無駄になります。HTMLやJSを使用する必要がないという主張はあまり意味がありません。使用しなくても、それを知る必要があります。最終的にはHTMLとJSにレンダリングされます。次に、それをデバッグしてみてください-簡単なもののために数日があることを確認してください。さらに、html / jsを知らないWeb開発者は想像できません。
なぜ人々がJava EEを直接使用する代わりにこれらの抽象化をすべて試しているのか理解できません。
質問に対する答えは、プロジェクトの要件によって異なります。メッセージキュー、コンテナー管理グローバルトランザクションなどのJava EE機能が必要ない場合は、tomcat + springを使用します。
また、経験から、多くのWebサービスの統合、スケジューリング、メッセージキューを必要とするプロジェクトは、Java EEスタックの一部を使用するのが最善であることがわかりました。良い点は、アプリケーションサーバーで実行されているJava EEモジュールと統合できるSpringを使用することです。
Java EE 6は以前のリリースとは大きく異なり、すべてが非常に簡単になります。Java EE 6は、多様なJavaコミュニティからの最高のアイデアを組み合わせています。たとえば、SpringフレームワークのRod Johnsonは、Java EE 6でのDependency Injection JSRの作成に積極的に関与していました。JavaEE 6を使用する利点は、ベンダーサポートなどのために一部の組織で重要になる可能性がある標準
GlassFish v3はJava EE 6をサポートしており、非常に軽量で起動が非常に高速です。私は開発にGlassfish v3を使用しており、設定は本当に簡単です。サーバーをグラフィカルに管理できる、非常にユーザーフレンドリーな管理コンソールが付属しています。
GlassfishV3とJSF 2を使用している場合は、Java EE 6のCDI機能を利用して、JSFで簡単に会話（ウィザードのようなページ）を作成できます。
そうは言っても、Java EE 6を使用するには、新しいAPIを学ぶ必要もあります。利用可能な時間枠によっては、それはあなたにとって最良の選択ではないかもしれません。Tomcatは古くからあり、tomcat + springの組み合わせは多くのWebプロジェクトで採用されています。つまり、多くのドキュメントやフォーラムが存在しています。
私はSpringとJava EE 6の両方で働いたことがあります。私の経験から言えることは、古くからあるJSPまたは独自仕様のFlexを使用している場合は、Springを使用していれば安全です。
ただし、JSFを使用する場合は、Java EE 6に移行する必要があります。JavaEE 6を使用すると、Faceletsと標準化されたスクリプトライブラリおよびコンポーネントライブラリに移行します。スクリプトの非互換性とコンポーネントライブラリマトリックスはなくなりました。
Spring MVCについては、プロジェクトが大きくなりすぎない限り、問題ありません。それが巨大なエンタープライズアプリケーションである場合は、Java EE 6に固執します。それが、独自のコンポーネントライブラリとリソースバンドルを整然とした方法で維持できる唯一の方法だからです。
Java EEフルスタックが必要な場合は、GlassFish 3.1をお勧めします。Java EE 6（JBoss 6、WebLogic 10.3.4）の一部またはすべてを実装する他のJava EEコンテナーと比較して非常に迅速に起動し、再デプロイには数秒かかり、ほとんどすべての構成を慣例に従って構成でき、非常に使いやすいです。
何か「軽い」が欲しいなら、Apache Tomcat 7.xを必要な機能でカスタマイズできます。私は次のライブラリで多く使用しました：Weld 1.1.0（CDI）JPA 2.0（Hibernate 3.6.x）-リソースローカルトランザクションのみJSF 2.x（Mojarra）RichFaces 4.0 BIRTランタイム
過去10年間（私は初期のEJB、JSF、およびWebテクノロジーに苦しんでいます）、Java EE開発者でした。JavaEE 6は非常に簡単で、適切に結合されており、現在のハードウェアはスムーズに動作するため、やる気のあるSpringが無効になっているという元々の理由があります。
私はまだ春を好みます。
そして私はJSFを渡します。死んだ技術だと思います。Spring MVCがより良い代替手段となります。したがって、フレックスになります。最初のXMLサービスを契約の観点から考えれば、バックエンドをUIから完全に切り離すことができます。
Glassfish v3とWeldがさらに成熟するまで待つことができない場合を除き、Spring + Tomcatをお勧めします。現在、CDI対応のアプリケーションでGlassFishを実行すると、メモリ消費/ CPU負荷にいくつかの問題があります。
すべてを読んだのではなく、Java EE 6のwar内でEJB3を使用できるようになり、TomcatでEJB3を使用できるようになったと思います（私はそう思います）。
SpringのTomcatをお勧めします。
重い処理が必要ないため、Tomcatを選択することをお勧めします