Java EE 6 vs.Spring 3スタック
私は今、新しいプロジェクトを始めています。テクノロジーを選択する必要があります。軽いものが必要なので、EJBやSeamは不要です。一方、JPA（Hibernateまたは代替）とJSFとIceFacesが必要です。
TomcatにデプロイされたSpring 3上のそのようなスタックは良い選択だと思いますか？または、Java EE 6 Webアプリケーションの方が良いでしょうか？ Java EE 6は新しいテクノロジーであり、まだ十分に文書化されていないことを恐れています。 Tomcatは、Glassfish 3よりも保守しやすいようです。
あなたの意見は何ですか？何か経験はありますか？
軽いものが必要なので、EJBやSeamは必要ありません。
EJB3以降、EJBが重くなっている理由を説明していただけますか？私たちはもう2004年ではないことを知っていますか？ your光とあなたの議論の定義を読みたいと思います（そして私は持っていると確信しているので、喜んで答えを更新します）言うべきいくつかの確かなこと）。
一方、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アプリケーションの方が良いでしょうか？
まあ、[〜＃〜] i [〜＃〜]非専有プラットフォームでコードを実行するアイデアのように （Java EE）独自のコンテナではなく（Spring）。そして、Java EE 6で十分だと思います（これはe曲表現、EJB 3.1（Lite）、JPA 2.0、JSF 2.0、CDIキックアスです）。JSF懐疑論者であったことに注意してください。しかし、もう一度見てみると、JSF 2.0とCDIは非常に異なっているため、比較することさえできません。
Java EE 6は新しい技術であり、まだ十分に文書化されていません。
Java EEは、私にはかなりよく文書化されています。これは無料請求のように聞こえます。そして、信じられないかもしれませんが、[〜＃〜] i [〜＃〜]Java EEが簡単になっている間、Springは複雑になっています。 。
Tomcatは、Glassfish 3よりも保守しやすいようです。
何か試しましたか？特定の問題に直面しましたか？繰り返しますが、これは無料請求のように聞こえます。
JavaEE6は使用していません。
ただし、以前のすべてのバージョンのJavaEEおよびEJBにひどくbeatられているため、デジュール標準だけでなく、デファクト標準としての地位を確立するまで信頼できません。現在、Springは依然として事実上の標準です。
一度私をだます、恥を知れ。恥ずかしがりながら、二度私をだます。 EJBを3回だます。
一部の人は、Springが所有権があると主張します。 JavaEE仕様のベンダー実装は、そうでないとしても、独占的であると主張します。
最近、多くのJavaアプリケーションをJBossからWeblogicに移動しました。すべてのSpring/Hibernateアプリは、必要なすべてのライブラリが組み込まれていたため、変更なしで移植されました。 JPA、EJB、JSFを使用していたすべてのアプリは移植に失敗しました。アプリサーバー間でのJPA、EJB、JSFの解釈の微妙な違いが原因で、すべての種類の厄介なバグが修正に永遠にかかりました。 AppServer間で完全に異なります。
Springは実装です。 JavaEEは仕様です。それは大きな違いです。仕様が100％気密であり、ベンダーがその仕様を実装する方法に揺らぎの余地がまったくない場合は、仕様を使用することをお勧めします。しかし、JavaEEの仕様はそれまでではありませんでした。おそらく、JavaEE6はより気密性が高いのでしょうか？知りません。 WARにパッケージ化できるほど、AppServerライブラリへの依存度が低くなるほど、アプリケーションの移植性が高くなります。結局、私がJavaとDotではなく-ネット。
仕様が密閉されていたとしても、すべてのアプリケーションのすべてのテクノロジースタックを一緒にアップグレードしなくても、アプリケーションサーバーをアップグレードできると便利です。 JBoss 4.2からJBoss 7.0にアップグレードする場合、すべてのアプリケーションに対するJSFの新しいバージョンの影響を考慮する必要があります。 Spring-MVC（またはStruts）アプリケーションへの影響を考慮する必要はありません。
関係ありません。 Java EE 6は十分であり、そこにあるプロファイルのために、「重い」ではありません-Webプロファイルを使用するだけです。
個人的には、私は春が好きです。しかし、私はJava EE 6 :)に対する合理的な引数が不足しています
（コメントで思い出されたように、 RichFaces 、および ICEfaces および/または PrimeFaces を試してみるとよいでしょう。あなたが必要です）。
最近、私のクライアントの割り当ての1つは、Springスタックとカスタムフレームワークスタックと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 EE 5 + Seam + GraniteDS + Flex
- Spring 3 + Vaadin（GWTで）
- Spring 3 + JSF 2.0（PrimeFaces）
私の共謀は次のとおりです。
- Spring 3はSeamよりもはるかに単純で（ほぼJava EE 6）、TomcatとJettyで実行されます！（mavenプラグインを使用した開発用のJettyはトラッシュです））。
- 私はFlexを愛しています（実際、私は長い間Flex開発者だったので偏見があります）。リッチインターフェースが必要で、FlashBuilderを購入できるなら、これを使用しますが、Spring + GraniteDSまたはBlazeDsバックエンドを使用します。 FlashBuilderを購入できない場合は、時間を無駄にしないでください。
- Vaadinは素晴らしいです！。開発プロセスはFlexよりも簡単ですが、HTMLの混乱なしにリッチなアプリケーションを簡単に作成できます。単一のJS行を記述しません。 CSSが必要なだけです（Flexでも必要です）。したがって、アプリケーションインターフェイスがデスクトップアプリケーションのように動作し、Flexを使用できない（または使用したくない）場合は、Vaadinを使用します。警告！ Vaadinには、ブラウザーに対する大きなJSオーバーヘッドがあります。
- よりシンプルなWebサイトのようなアプリケーションを作成する場合は、JSF2.0を使用します（上記のスプリングバックエンドを使用）。 HTMLと戦う必要があります（私は嫌いです）。リッチなインターフェイスを作成することはVaadin（特にレイアウト）より難しくなります。遅いブラウザー/コンピューター用の軽量HTMLを取得します。私はPrimeFacesが好きです-それは簡単で、よく文書化されています。 2位はIceFacesです
- （ブラウザに適合するエンタープライズアプリケーションを作成する代わりに）HTMLに命を吹き込む必要があるWebサイト（Webアプリケーションではない）を作成する場合は、Wicket（コンポーネントベースを好む場合、プル態度）またはSpringMVC（テンプレートベースを好む場合）を使用します、プッシュ態度）または単にPlayを使用してください！フレームワーク。リッチなデータベースのコンポーネントを作成することははるかに困難ですが、htmlの各タグを制御できることに注意してください（HTML /グラフィックデザイナーはそれを気に入っています）
私の意見は、他の人が言及していないことに基づいています。つまり、私の仕事のコードは何十年も（文字通り）生きる傾向があり、したがってメンテナンスは私たちにとって非常に重要です。独自のコードと使用するライブラリのメンテナンス。私たちが制御する独自のコードですが、使用するライブラリがothersによって上記の数十年以上維持されていることは興味の対象です。
簡単に言えば、これを実現する最良の方法は、Sun仕様のオープンソース実装をraw JVMまで使用することであると結論付けました。
オープンソースの実装のうち、Apache Jakartaはライブラリを維持することが実証されており、最近SunはGlassfish v3の高品質な実装の作成に多くの仕事をしました。いずれにせよ、すべてのモジュールのソースも用意されているため、他のすべてが失敗した場合でも、それらを自分で管理できます。
通常、Sunの仕様は非常に厳密であるため、仕様に準拠する実装は簡単に交換できます。サーブレットコンテナをご覧ください。
この特定のケースでは、JavaServer FacesをJava EE 6の一部であるため、JavaServer Facesをご覧になることをお勧めします。 MyFaces Tomahawkで拡張することを選択しました。いくつかの便利な追加機能があり、ジャカルタプロジェクトです。
JBoss Seamまたは他のユーザーには何も問題はありません。私たちにとって非常に重要なのは、メンテナンスの問題に対する彼らの焦点が少ないということです。
Adam Bienの Future Of Enterprise Java ... Is Clear（Java EE with Spring and Vice Versa） を読んで、コインの両面を取得するためのコメントを含めてください。いくつかの理由からSpringを選択します
「あなたが話しているのはどちらのJava EE 6サーバーかわかりません。Glassfish認定とTMAX JEUSがあります。Java WebSphere、WebLogic、JBossなどのEE 6準拠バージョンは本番環境にあり、実際のアプリケーションに使用できます。Spring3では、Java 1.5およびJ2EE 1.4が必要です。ほとんどすべての環境
既に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スタックのいくつかを使用するのが最適です。それでも、Javaアプリケーションサーバーで実行されているEEモジュールと統合します。
Java EE 6は以前のリリースとは非常に異なり、本当にすべてが非常に簡単になります。 Java EE 6は、多様なコミュニティからの最高のアイデアを組み合わせていますJavaコミュニティ-たとえば、SpringフレームワークのRod JohnsonはDependency Injection JSRの作成に積極的に関与しました。 Java EE 6. Java EE 6を使用する利点は、ベンダーサポートなどのために一部の組織で重要になる可能性がある標準に従ってコーディングすることです。 。
GlassFish v3はJava EE 6をサポートし、非常に軽量であり、非常に高速に起動します。開発にglassfish v3を使用しており、設定は非常に簡単です。サーバーをグラフィカルに管理できる非常に使いやすい管理コンソール。
GlassfishV3とJSF 2を使用している場合は、Java EE 6のCDI機能を利用できます。これにより、JSFで会話（ページのようなウィザードなど）を簡単に作成できます。
そうは言っても、Java EE 6を使用するには新しいAPIを学ぶ必要があります。利用可能な時間枠によっては、最適な選択肢ではない場合があります。 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 runtime
過去10年間Java EE開発者でした（初期のEJB、JSF、およびWebテクノロジーに苦しんでいます）Java EE 6は非常に簡単で、うまく結合され、現在のハードウェアはスムーズに動作しますやる気のあるSpringがもはや有効ではない理由。
私はSpringとJava EE 6の両方で働いてきました。私の経験から言えることは、古いJSPまたはプロプライエタリなFlexに行くなら、Springにとどまるなら安全だということです。 。
ただし、JSFを使用する場合は、Java EE 6に移行してください。Java EE 6およびコンポーネントライブラリ：スクリプトの非互換性とコンポーネントライブラリマトリックスはもうありません。
Spring MVCに関しては、プロジェクトが大きくなりすぎない限り問題ありません。巨大なエンタープライズアプリケーションの場合、Java EE 6に固執します。これが、独自のコンポーネントライブラリとリソースバンドルを整然と維持できる唯一の方法だからです。
私はまだSpringを好むでしょう。
そして、私はJSFを渡します。私はそれが死んだ技術だと思う。 Spring MVCはより良い代替手段です。 Flexもそうです。コントラクトファーストXMLサービスの観点から考えると、バックエンドをUIから完全に切り離すことができます。
すべてを読みませんでしたが、TomでEJB3を使用できるようにJava EE 6での戦争の中でEJB3を使用できるようになったと思います。
Glassfish v3とWeldが成熟するまで待つことができない限り、Spring + Tomcatをお勧めします。現在、CDI対応アプリケーションでglassfishを実行すると、メモリ消費/ CPU負荷にいくつかの問題があります。