Java Web Application Framework総合　ver2

1 ：2013/07/21 〜 最終レス ：2013/10/13

Java用のWeb Application Frameworkについて語るスレッド
海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド
前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/
Web Application Framework　のリスト
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features

2 ：

【関連スレッド】
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
http://toro.2ch.net/test/read.cgi/tech/1220671877/
【DI】Java Spring Frameworkを語るスレ 5.0
http://toro.2ch.net/test/read.cgi/tech/1322414231/
以上、テンプレ終わり。
需要があるかわからんけど立ててみた。

3 ：

>>1乙
ASP.NETの話題が増えてたしスレタイからJava外してもよかったかもな
あるいはASP.NETは専スレ立ててそっちでやってもらうか

4 ：

どう考えてもASP.NETが他所でやるべきだろ

5 ：

ASP.NETはJavaみたいにフレームワーク同士の組合せとかあんまり無くって、
ASP.NET MVCか、古い方のASP.NETくらいしか無いからな。
JavaはWeb層、DIコンテナ、OR/Mと色んな組合せがあるから、
難しい反面、語ることも色々あるんだよね。
と言いつつ、Struts1.xを仕事で使ってるんだけどね。
ちょこちょこカスタマイズしながら。
フレームワークを上手く使えば量産型PGを大量に投入できるので、
工数削減に寄与できるんだよね。
JSP/Servletしか使わないとか、オレオレフレームワークとか言ってるのは、
ビジネスセンス疑いますよ、ええ。
あと、どうせオプソのサポートなんて合って無い様なもんなんだし、
自前でコード読んでサポートできる技術力は会社に一人くらいは必須だよね。

6 ：

１アクション１メソッドで中に何百ステップ書かれてようと気にしない
量産型PGで生産性に拘るなら当然の選択

7 ：

>>2に追加
△△もっとStruts2の良さを教えてくださいSsssion6
http://toro.2ch.net/test/read.cgi/tech/1217536023/
【Java】Play framework【Scala】
http://kohada.2ch.net/test/read.cgi/php/1304277057/
Tapestryについて語ろうよ！
http://toro.2ch.net/test/read.cgi/tech/1067531714/
【Java】Wicket【HTML】
http://toro.2ch.net/test/read.cgi/tech/1132407308/

8 ：

>>3-4
ASP.NETとASP.NET MVCのスレはすでにある。
ここはそのままでいいよ
ASP.NET系は一番人気あるフレームワークだから、
どういうスレタイにしてもASP.NET系の話題は出てくる。
ASP.NET MVC
http://kohada.2ch.net/test/read.cgi/php/1331013877/
【質問】ASP.NETスレ Part7【雑談】
http://kohada.2ch.net/test/read.cgi/php/1343282128/
【消しゴム】MONOを使ってみるスレ4【じゃない】
http://toro.2ch.net/test/read.cgi/tech/1329023778/
>>1 乙

9 ：

結局生ServletとかJSPとか言っているのは開発にスケールもスピードも求められて
いなくて、そのくせ一度作ったサービスを見直しもリニューアルもせず延々と延命
させ続ける客相手の受託開発メインってことかなぁ。面白く無さそう。

10 ：

最近angularjs + playframework2(scala,coffeescript,less)を使い始めたんだけど、すごく使いやすいよ。
.NET MVCと比べても作業効率が高い。でも、scalaだとスレ違いか。

11 ：

Scalaはいずれ抑えたいけど業務アプリだと出番がないな

12 ：

Struts1使ってるやつがビジネスセンスどうのこうのw
利益率上げたければ生産性低いStrutsはないだろ

13 ：

ScalaはJavaの代替として考えた時期もあったが
うんこフレームワークしかないのでやめた
Play!はsessionがなかったりかなり変なフレームワークで
汎用的に使えるものじゃなかった。
Lift はものすごく使いづらくひどいものだった。
Scalaはコンパイルが遅いのも問題でイライラした。
けっきょく、ASP.NET MVCが最強だった

14 ：

ScalaがSession持ってたまるか
何のための関数型なんだか

15 ：

ぜんぜんレイヤーが違うじゃん
どんな言語でもセッションは必要だろ

16 ：

>>5
商用のなんて使ってもバグなんて直してくれないだろうに……
というのがＯＳＳに流れてついてきた奴の流れじゃろ。

17 ：

playframeworkは基本ステートレスだけど、セッション持ってるよ。
まぁ、servletとは全く別物だから取っ付きにくいかもだけど、playの方が扱いやすい。
一言で言うと、Java on Rails。試してみて損は無い。
scalaがコンパイル遅いのは同意。

18 ：

play2のview templateがクソだけど、
angularjsと一緒に使うことで生まれ変わる。

19 ：

自社プロダクトだからスケールやスピードよりも
より安定してより細かい制御が作りこめて寿命が長くないといけないから
やっぱりJSP&Servletがいいかな。

20 ：

Java on RailsをのたまうならGrailsを無視するな〜

21 ：

Scalaは気になるんだけど、コンパイルの遅さとか、その辺については実際どうなの？
実際に使っている人の話が聞きたいけど。
あと、個人的にはPlayよりScalatraが気になるかな。

22 ：

Scalaは戀塚氏のお気に入り

23 ：

JAX-RSはCDIのConversationScopedと組み合わせると業務でも行けそうだ

24 ：

Scala推せば通ぶれる、という雰囲気があるのは確か

25 ：

ConversationScopedと組み合わせなくても普通に業務で使っているけれどもね > JAX-RS

26 ：

>>21
scalaはコンパイルが本当に遅い。ここはなんとかして欲しい。
まぁコンパイルの遅さを差し引いいても、開発効率やメンテナンス効率が高いから全体で見るとそれ程問題ない。
コンパイルなんてほっとけば終わってるし。
Scalatraも使いやすい。Servlet派の人はこっちの方がいいかもね。
>>20
Grails？GroovyはGradleレベルのちょっとした物書くにはいいけど、
本格的なプロジェクトでは使いたくないな。
Groovyの作者もScalaを知ってたらGroovyなんて作らなかったって言ってるからね。
http://www.infoq.com/jp/news/2009/07/scala-replace-java

27 ：

>>26
印象論や伝聞だけで敬遠されているのならやや勿体ないな > Grails
Grailsの良いところはGroovy云々以前にまずSpring MVCベースのフルスタックの
フレームワークとして一番普及していてメンテもされていること。
Javaで書かれたSpringベースの成果物にWebのUIを与えるのに一番の近道。
あとGroovyに関してはこれで大切なロジックを書くことまでは期待していない。
うちの会社もバックエンドやGrailsで使うにしても抽象クラスの類はJavaでカッチリ
書いている。
あとGroovyはグルー言語としてとても優れていて、Javaでカッチリ書かれたものを
Groovyでサクッと拡張してからデプロイするといった用途に便利。

28 ：

おいときますね
下2行は辞めた先輩が実際に歌った歌詞だよ☆ミ
ヤバ 破綻した グルーで補修した
それだけで なんか達成感
大事なのは QCD あと利益率ゥゥゥゥゥッ⁈
コストを 下げなきゃ 基盤の意味がない

29 ：

結局普及に失敗したものは廃れる運命だからな

30 ：

Hibernate同様にGrailsも認知度の日本国内外の差は妙なところだなぁ。
http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013
PlayとGrailsの比較とか。
http://www.slideshare.net/mraible/play-vs-grails-smackdown-devoxx-france-2013

31 ：

Scalaやっている人は、参考までに使っているツール(IDE、他)を教えてくれないかな？

32 ：

>>31
Eclipseベースは古いバージョンしかつかえない
Scalaスレ情報では
ScalaのIDEはIntelliJ IDEAが一番人気らしいよ
自分で使った感じでもIDEAが一番ましだった。
compile遅いうえに、よいフレームワークがなかったから
俺はscala自体捨てた
言語はJavaよりましだけどライブラリ、フレームワークといった
エコシステムが充実していない。
ScalaはOSSも盛り上がりに欠けている。

33 ：

ScalaはCPUリソースを使い切るような環境でもなければ出番が無さそう
AWSにデプロイできるScalaベースのソーシャルアプリとか出たら話は変わるかも

34 ：

寺田氏曰くGF4はまだ安定版じゃないとのことだがJerseyの2系(今は2.1)も同じかな？

35 ：

roadmapを見るに今年中に4.0.1が出るらしいが
本番で来年出るらしい4.1からかな、商用サポート始めるみたいにあるし

36 ：

The Curious Coder’s Java Web Frameworks Comparison:
Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF
http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/
ここでもGrails...
Documentationが評価5だけど確かにGrailsの公式リファレンスは使いやすい。

37 ：

JSFが23%ってヤツら狂ってるな

38 ：

http://taichi.hatenablog.com/entry/2013/08/06/171524
Groovyの基礎的な文法を紹介する所から丁寧に書きました。
だそうだ

39 ：

毎日何かが半額のmanningが今日はGroovy関係
プロモーションコードはdotd0806
Gradle in Action
http://www.manning.com/muschko/
Grails in Action, Second Edition
http://www.manning.com/gsmith2/

40 ：

制作者がScalaを知ってたら作らなかったとか言ってた言語なのに人気あるんか

41 ：

Scalaを知っていたら敢えて新しい言語を作るまではしなかっただろう
というだけの話で、Groovyが劣っているとかそういう話じゃないだろ

42 ：

Java知っていれば学習コストはかなり低そうだからな〜 > Groovy

43 ：

>>40-41
Scalaもコンパイル遅いし大したことないよ
たいして人気もでてない

44 ：

>>40
Grailsだから流行ったフレームワークではなく、まず良く出来たフレームワークが
あって、それを使うことからGroovyを再発見した人も多いのでは。
RailsやPlay!もそうだよね。人気のあるフレームワークがその言語の新規ユーザを
増やす呼び水になっている。
フレームワークとしてはGrailsは良く出来ていると思う。でかいけどね。

45 ：

Glassfish3.1.22なんだけどj_security_checkで認証すると
認証前のリクエストがPOSTだった場合でも認証後に再びPOSTされるんだよな。
なんかChrome見ると302の後にChromeはちゃんとGETでアクセスしてるから
Glassfishが認証フィルタあたりで何かきもいことやってるんだろうけど
HttpServletRequest#login使った手組だとどうにも再現できん。

46 ：

HTTPの仕様上、302はメソッドを変えずにリダイレクトするのが正しい(前がPOSTなら後もPOST)
しかしほとんどのブラウザは常にGETでリダイレクトするのでHTTP 1.1で303と307が追加された
303は常にGETでリダイレクトする (現実の302と同じ)
307はメソッドを変えずにリダイレクトする (仕様上の302と同じ)
Glassfishは303を使ってるとか？

47 ：

最後の一行間違った
Glassfishは307を使ってるとか？

48 ：

Glassfishは302を返してるよ。メジャーなブラウザは302にGETを返すらしい。
あとChromeは303にはGET、307には前回と同じメソッドとこちらはちゃんとしてくれる。
どうもGlassfishはj_security_checkの段階ではなく、
次のリクエストで認証してるみたい（Set-Cookieのタイミングがここ）
BASIC認証と動きを合わせるためにきもいことしてるんだろうなぁ
JBOSS ASとかも後で確認する

49 ：

きもいきもい言いすぎ
どうしたのってば

50 ：

どうやらこの現象はTomcat側にmaxSavePostSizeってプロパティで設定できるらしいね
Glassfishはどうやって設定するのかまだ分からないけど、JBoss AS7.1.1は無効にしてるっぽい

51 ：

wicketはダメ？

52 ：

Viewをサーバ側で動的に生成する仕組みが
そもそもオワコンになってきてる気がする
MVCのMCだけサーバ側で担当してVはHTML5+JS+CSS3
連携はJSONかpjaxで。

53 ：

WPFはWebのページアプリの概念を取り込んだが
Webは逆にSDIアプリの概念にシフトし始めてるのかもな

54 ：

>>52
またそうやって「JSON返すのはサーバサイドFW不要論そのもの」
「その不要論を言いだすと、Java不要論になるしこのスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定」厨を煽る作戦ですね

55 ：

誰が一番煽っているんだか

56 ：

(・ω<) ﾃﾍﾍﾟﾛ

57 ：

サーバ側はJSONだけを返せればそれで良い、…そう思っていた時期が、私にもありました(´・ω・`)

58 ：

HTMLフラグメントをサーバから非同期で返す
pjaxてのがあるのか。よさげだな。

59 ：

狭義(jQueryプラグイン)のPjaxは何年か前に話題になっただけでオワコン臭

60 ：

よくわからんがInnerHTMLに直接代入できるテキストをくれる感じか

61 ：

javascriptでJSONパースしてはめてくって処理が要らなくなるのはええね

62 ：

pjaxは結局動的にHTMLフラグメントを生成するのに従来同様にJSPの類を使う事になる。
なので静的なページが中心で一部だけ動的にしたい場合など無理にJSONでやりとりするより
楽だし、動的でかつクローラブルでハイパーリンク可能にするのもJSON使う場合より手間は
少ない。

63 ：

>>57
一度挑戦したが結局挫折したわー。
最近のサーバーの性能だとよっぽど大規模なユーザー数のアプリじゃないと
そこまでするメリットがない上に実例がなくてだるい。

64 ：

JSONで済む割合はサイト毎に全然違うしょ
スマホネイティブアプリ向けサイト＞＞＞＞シングルページアプリ向けサイト＞＞＞＞旧来的なサイト

65 ：

つーかね、HTMLのフラグメント返した方が更新が綺麗だったり、仕組みが単純だったり、JSONよりそっちの方が良いや、ってなっちゃったりもして。

66 ：

サーバ側でやる処理と、クライアント側でやる処理を
どこで区切るかってだけの話だよね
スマホ向けWebアプリだと、意外とJSONのほうが小回り利いたりする

67 ：

HTMLのフラグメントっていうのは、partial view というか、部分的なHTMLのこと？
(<div> のなかみだけ、とか)
JS で innerHTML でさしかえる用、とか。

68 ：

そんなイメージ
jQuery使うようになってからは素のJS書かなくなって
innerHTMLとかもう遠い昔

69 ：

サーバサイドの人がJSP書きながらちょっとjQuery使うだけならPjaxいいかもね
クライアントサイドの人はBackboneやAngular、つまりテンプレートエンジンや
データバインディング使うから無用だけど

70 ：

TwitterがHTMLのフラグメントを使う様にしたとかいう話ってなかったっけ？
あれって、どういう理由でそうなったの？

71 ：

初回表示が遅くなった対策に一発目はHTML返すよう戻したって話？
表示後は今でもJSON(コンテントタイプはtest/javascriptでgzip圧縮されてる)でタイムライン更新してる

72 ：

デザインサイドだとどの程度ライブラリに依存するのがトレンドなんだい？
jQuery + Normalize.css あたりで頑張るのか、Twitter Boostrapとか使うのか

73 ：

>一発目はHTML返す
HTMLに<script>タグで囲んだJSON一緒にくっつけて
返すとかはよくやるな。リクエスト減らす目的で。
Boostrapは便利なんだけど、アレ使うとLook&Feelがまんま
Boostrapテイストになっちゃうんで、デザインちゃんと
考えてるプロジェクトだと意外と使わない。
CSSの学習素材としては素晴らしいが。
HTML5-Boilerplate + jQuery + 独自CSSって感じかな。
Normalize.cssも使う。

74 ：

クライアントサイドでもサーバーサイドでもどちらでも良いけれども、JSONとか
使うREST APIを開発するにあたって認証はどの方式を使っている?

75 ：

>>74
サーバサイドの REST API の場合は、クライアントがブラウザとは限らないため、
完全なステートレスでの利用を前提にハンドシェイク後にキーを発行して、
クライアントは受け取ったキーを常にパラメータとして付与しながら API を叩く
仕様にしてる。
一旦キーが発行された後は、サーバ側では、渡されたキーと接続先アドレスを
使って認証の判定をしている。自分のシステムの場合は、複数のツール/システム群から
順に連携して叩かれる事もありうるから user-agent の判定とかはあえて行っていない。
あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
使われていないキーは一定期間が経過したらどんどん失効（削除）させてる。
実運用では律儀に終了処理なんて呼んでくれない奴の方が多いからね。
誰もが使えてもいい公共性のある API なら、そもそもそんな仕掛けも要らないだろうけれど、
緩い個体の識別から、サーバ側に登録された ID が持つ権限内容との紐付けをした上での
識別までハンドシェイク部分の作り方次第で自由に切り替えられるから、自分が最近作った
システムは大枠としてはどれもそういう作りにしてるかな？

76 ：

>>75
> サーバ側では、渡されたキーと接続先アドレスを使って認証の判定をしている
接続元IPアドレスを認証に使うのは、IPアドレスの偽装もあり得るので危険なのでは？
と思ったが、 >>75 さんの環境がイントラ内とかだったら、わりきってそれもありかな、と思った。
(イントラネット内で、ちゃんとIPアドレスや、それがどんなサーバなりスイッチか、などが管理されていれば)

77 ：

IPアドレスは保険みたいなもんで認証の主はキーでしょ？

78 ：

AWS方式でリクエストをHMACで署名。

79 ：

巷のAPIはSSLを使った上でAPI Keyでリクエスト署名ってパターンが多い気がする。
うちもそうしている。
HTTP Method name + Request Path + Timestamp + bodyからHMAC-SHA1計算して
HTTPヘッダに埋め込む。
ただこれだとクライアントの開発時にAPIをテスト目的でcurlとかで叩くことが
面倒なので、同じキーでBasic認証も出来るようにしている。

80 ：

SSL+BASICじゃダメなの？

81 ：

サーバではコミットしたけどクライアントで反映失敗とか
セッションハイジャックをかんがえると
OTPとはいかないまでもシリアル値くらいないとダメな場合もある。

82 ：

>>80
認証だけなら良いと思うよ。SSLをかましているのであれば。
ただSSL経由とはいえ秘密鍵を平文で投げたくない、かつステートレスにしたい
のであれば自ずとリクエストと秘密鍵から計算したハッシュ値で署名するという
解決策にたどり着く。
仮にリクエストがのぞき見されても秘密鍵は漏れないし、ハッシュ値を計算する
データの中にタイムスタンプを含めておけばリプレイ攻撃にも多少は強くなる。

83 ：

なるほど、勉強になります。

84 ：

>>82
>>75と同じ人だよね？
>>75じゃサーバからクライアントにキーを渡すことになってるけど、それが秘密鍵？
だとしたらレスポンスのぞき見されたら秘密鍵漏れない？
「SSL経由とはいえ秘密鍵を平文で投げたくない」になってるのか疑問なんだが
さらに、「かつステートレスにしたい」と続いてるが>>75の以下を見るにステートレスに
なってなくね？
> あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、

85 ：

>>84
違う人です。すまん。

86 ：

>>85
別人か、正直すまんかった
それでクライアントの秘密鍵ってどう扱ってる？
サーバから渡すんじゃ「SSL経由とはいえ秘密鍵を平文で投げたくない」は難しそうなんだが
クライアントがイントラ内の別サーバなら楽だけどJSとかだと…

87 ：

>>86
API Keyはセッション毎の使い捨てではなく永続的なものね。
うちのシステムでは顧客、というかデベロッパにはまずユーザ登録をしてもらって、あとは
Webブラウザから管理ダッシュボードにログインしてAPI Keyを好きなだけ生成したり既存の
キーを無効にしたり出来る。
秘密鍵の文字列はまぁ、管理ダッシュボードのWeb画面からコピペw
でもAPI Keyを使った認証を提供しているサービスはこのやり方が多いと思う。

88 ：

画面をさくさくっと作っていきたいんですが、なんかいいフレームワーク無いですかー？

89 ：

>>88
ASP.NETがおすすめ

90 ：

貴方が書き込んだのはこの銀のループするスレですか?
それともこちらの金の過疎るスレですか?

91 ：

>>88
好きなもの使いなはれ
ttp://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

92 ：

Grails2.3か。
新機能はともかくivyを捨ててMavenと同じ依存性解決エンジンを使うように
なるのが嬉しいな。SNAPSHOTやclassifier周りのタコな動作がようやく解決。

93 ：

Struts2もSpring2もまだ現役だというのにSeasar2ときたら…

94 ：

やっぱり日本産は駄目だな！

95 ：

ひとめぼれ、うまー

96 ：

>>93
うちSeasar2バリバリ現役です・・・。
Spring2はいいとして、Struts2なんて欠陥品だろ。

97 ：

>>95
時代は今、コシヒカリですよ！
http://i.imgur.com/sP8Stc9.jpg

98 ：

そこでStruts1.2が現役な私の会社の出番ですよ。

99 ：

>>93
今更GWTに手を出そうとしてる人でしょ？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

■暗号技術【ROUNDsurea】■ (574)
MSX-BASICの奥義を伝授するスレ (782)
Windowsストアアプリ開発について語れ (114)
音声合成プログラムを作りる (326)
Androidプログラミング質問スレ Part37 (214)
【上流社会】MSDNサブスクリプション総合【最先端】 (652)
--log9.info------------------
新動詞『レガる』38 (308)
【ドラマ２４】 リミット4 【テレビ東京】 (660)
【2015年】大河ドラマ予想スレ8 (695)
〔☆〕八重の桜の視聴率について語るｽﾚpart27〔☆〕 (449)
【2013年大河ドラマ】八重の桜アンチスレPart10 (129)
【2014年大河ドラマ】軍師官兵衛 Part3 (114)
【2013年大河ドラマ】八重の桜 Part96 (482)
【2014年大河ドラマ】軍師官兵衛の予想キャスト11 (124)
【得子】　松雪泰子　【美福門院】 (315)
〓平〓清盛の年平均視聴率はシエを超える！〓平〓 (129)
【一目惚れ】武井咲の常盤御前を語ろう！ (413)
奈良岡朋子嫌い。何か感じ悪い。 (133)
結局さあ、「義」って何なの？ (111)
尾野真千子さんの出演を待ちわびるスレ (364)
【ネタバレ】龍馬伝ノベライズ専用スレッド (533)
大河「江〜姫たちの戦国」第一話・天命の姫 (144)
--log55.com------------------
【上野】　徳大寺　【摩利支天】
荒神社(立里荒神社)
【河内国一之宮】 枚岡神社 【元春日】
【必勝】 勝運向上出世成就no神社寺院 【武運】
よそのお守りやお札を燃やしてくれるとこ
毎日裏の寺の騒音に悩まされています
初詣は１月１日以外認めません！
杉並大宮八幡宮