今、新しいプロジェクトを始めています。テクノロジーを選択する必要があります。軽いものが必要なので、EJB や Seam は必要ありません。一方、JPA (Hibernate または代替) と JSF と IceFaces が必要です。
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 を見ていない方のために、CDI がすばらしいことをお伝えします。
残念ながら、Java EE 6 は新しいテクノロジーであり、まだ十分に文書化されていません。
Java EE はかなりよく文書化されているように見えます。これは自由請求のように聞こえます。そして、信じられないかもしれませんが、Springが複雑になり、Java EE がより簡単になっていることに気づき始めました。
Tomcat は Glassfish 3 よりも保守が容易なようです。
何か試してみましたか？特に問題はありませんでしたか？繰り返しますが、これは自由請求のように聞こえます。
私はJavaEE6を使用していません。
ただし、以前のすべてのバージョンのJavaEEおよびEJBにひどく殴打されたため、デジュリスタンダードだけでなくデファクトスタンダードとして確立されるまで信頼できません。現在、Springは依然として事実上の標準です。
一度私をだまして、あなたを恥じてください。私を二度騙して、恥をかかせてください。私を3回だまして、EJB。
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を使用する理由です。
仕様が気密であったとしても、すべてのアプリケーションのすべてのテクノロジースタックをアップグレードしなくても、アプリサーバーをアップグレードできると便利です。JBoss4.2からJBoss7.0にアップグレードする場合は、新しいバージョンのJSFがすべてのアプリケーションに与える影響を考慮する必要があります。Spring-MVC（またはStruts）アプリケーションへの影響を考慮する必要はありません。
それは問題ではありません。Java EE 6 で十分です。プロファイルがあるため、「重く」はありません。Web プロファイルを使用するだけです。
個人的には春が一番好きです。しかし、私はJava EE 6に対する合理的な議論を使い果たしています:)
（コメントで思い出したように、必要なコンポーネントに応じて、 RichFacesだけでなく、ICEfacesやPrimeFacesも試してみてください）。
最近、私のクライアントの割り当ての1つに、SpringStackとカスタムフレームワークスタックとJavaEE標準の評価が含まれていました。1か月の評価とプロトタイピングの後、私は満足しただけでなく、JavaEE6の機能セットに驚かされました。2011年以降の新しい「エンタープライズ」プロジェクトアーキテクチャでは、Java EE 6と、Seam3や今後のApacheJSR299拡張プロジェクトなどの潜在的な拡張機能を使用します。Java EE 6アーキテクチャは合理化されており、過去数年間に進化した多くのオープンソースのアイデアの中で最も優れたものが組み込まれています。
すぐに使用できる次の機能を検討してください。イベント管理、コンテキストとDI、インターセプター、デコレーター、RESTful Webサービス、埋め込み可能なコンテナーとの統合テスト、セキュリティなど。
私の結果のほとんどは、役立つと思われるJavaEE6の主要な概念を説明するブログに公開されています。
もちろん、フレームワークを選択するための厳格なルールはありません。Java EE 6は、豊富な会話セッション状態を必要としない、より単純な「Webサイト」には十分に肥大化する可能性があります。GrailsまたはPlayを選んだ方がいいでしょう！フレームワーク。しかし、会話型Webアプリケーションの場合、JavaEE6が適切でない理由についてのより良い議論はわかりません。
さて、しばらくして、スタックの経験があります：
私の結論は次のとおりです。
Adam Bien のFuture Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa)を読んで、コインの両面を取得するためのコメントを含めてください。私はいくつかの理由でSpringを選択します。以下はその1つです（投稿からのコメントの1つを再現）
'どの Java EE 6 サーバーについて話しているのかわかりません。Glassfish認定とTMAX JEUSがあります。WebSphere、WebLogic、JBoss などの Java EE 6 準拠のバージョンが本番環境にあり、実際のアプリケーションに使用できるようになるまでには、かなりの時間がかかります (読み: 年)。Spring 3 には Java 1.5 と J2EE 1.4 が必要なだけなので、ほとんどすべての環境ですぐに使用できます。
私の意見は、他の人が言及していないことに基づいています。つまり、私の仕事のコードは (文字通り) 何十年も存続する傾向があるため、メンテナンスは私たちにとって非常に重要であるということです。独自のコードと使用するライブラリのメンテナンス。私たちが管理する独自のコードですが、私たちが使用するライブラリが上記の数十年以上にわたって他の人によって維持されていることは私たちの利益になります。
簡単に言うと、これを実現する最善の方法は、生の JVM に至るまで Sun 仕様のオープン ソース実装を使用することであると結論付けました。
オープン ソースの実装のうち、Apache Jakarta はライブラリを維持していることを証明しており、最近では Sun が Glassfish v3 の高品質の実装を作成するために多くの作業を行っています。いずれにせよ、すべてのモジュールのソースも用意されているので、他のすべてが失敗した場合でも、それらを自分で保守できます。
通常、Sun の仕様は非常に厳密であり、仕様に準拠する実装は簡単に交換できます。サーブレットコンテナを見てください。
この特定のケースでは、JavaServer Faces を検討することをお勧めします。これは、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を直接使用する代わりに、なぜ人々がこれらすべての抽象化を試みているのか理解できません。
2010 年になっても、EJB がヘビー級であるといううわさがまだあるのはなぜですか? 人々は Java EE テクノロジーで更新されていないようです。試してみてください。Java EE 6 で物事がいかに単純化されているかに驚くことでしょう。
質問に対する答えは、プロジェクトの要件によって異なります。メッセージ キューやコンテナー管理のグローバル トランザクションなどの Java EE 機能が不要な場合は、tomcat+spring を使用します。
また、経験から、多くの Web サービスの統合、スケジューリング、メッセージ キューを必要とするプロジェクトは、Java EE スタックの一部を使用して行うのが最適であることがわかりました。良いことは、Spring を使用して、アプリケーション サーバーで実行されている Java EE モジュールと統合できることです。
Java EE 6 は以前のリリースとは大きく異なり、すべてが非常に簡単になります。Java EE 6 は、さまざまな Java コミュニティからの最高のアイデアを組み合わせています。一部の組織では、ベンダー サポートなどのために重要になる可能性がある標準。
GlassFish v3 は Java EE 6 をサポートし、非常に軽量で起動が非常に高速です。私は自分の開発に Glassfish v3 を使用していますが、設定は非常に簡単です。サーバーをグラフィカルに管理できる、非常に使いやすい管理コンソールが付属しています。
GlassfishV3 と JSF 2 を使用している場合は、Java EE 6 の CDI 機能を利用できます。これにより、JSF で会話 (ウィザードのようなページなど) を簡単に作成できます。
そうは言っても、Java EE 6 を使用するには、新しい API を習得する必要もあります。利用可能な時間枠によっては、最適な選択ではない場合があります。Tomcat は何年も前から存在しており、Tomcat と Spring の組み合わせは多くの Web プロジェクトで採用されています。つまり、多くのドキュメントやフォーラムが存在します。
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 年間 Java EE 開発者であり (私は初期の EJB、JSF、および Web テクノロジーに苦しんでいます)、Java EE 6 は非常に簡単で、よく結合されており、現在のハードウェアはスムーズに動作するため、Spring を動機付けた当初の理由はもはや有効ではありません。
私は Spring と Java EE 6 の両方で働いてきました。私の経験から言えることは、古い JSP または独自の Flex を使用する場合は、Spring を使用していれば安全だということです。
しかし、JSF に移行する場合は、Java EE 6 に移行する時期です。Java EE 6 では、Facelets と標準化されたスクリプト ライブラリとコンポーネント ライブラリに移行します。スクリプトの非互換性やコンポーネント ライブラリ マトリックスはもうありません。
Spring MVC に関しては、プロジェクトが大きくなりすぎない限りは問題ありません。それが巨大なエンタープライズ アプリケーションである場合は、Java EE 6 に固執します。それが、独自のコンポーネント ライブラリとリソース バンドルを整然と維持できる唯一の方法だからです。
私はまだ春の方が好きです。
そして、私はJSFを渡します。死んだ技術だと思います。Spring MVC はより良い代替手段です。フレックスもそうです。コントラクト ファースト XML サービスの観点から考えると、バックエンドを UI から完全に切り離すことができます。
すべてを読んだわけではありませんが、Java EE 6 の戦争内で EJB3 を使用できるようになったため、Tomcat で EJB3 を使用できるようになりました (と思います)。
Glassfish v3 と Weld が成熟するまで待つことができない場合は、Spring + Tomcat をお勧めします。現在、CDI 対応アプリケーションで Glassfish を実行すると、メモリ消費/CPU 負荷にいくつかの問題があります。
Springを使用したTomcatをお勧めします。理由は次のとおりです。
重い処理を必要としないため、Tomcatを選択することをお勧めします