発表資料は以下
今回の目的は、"Springはまだまだ進化している"ということを伝えることでした。なので、キラキラ感を出すために、あえて新機能や流行の技術との絡みを多めに含めました。
ぶっちゃけ業務ではこういう使い方はしないかな～と思うようなことも"意識の高いエンジニア"向けにあえて説明しています。現場から遠く感じるというようなつぶやきが見えたように感じましたが、今回の目的は現実的なやりかたを伝えるわけではなかったので、そう思われても仕方ありません。
現場で使うためのテクニックはまた今度リリースします（たぶん）。こうご期待。
発表の後に受けた質問とその回答(補足込)を以下に記載します。
質問その１
Spring Securityは本当に使える？認証って業務ロジックそのものだと思うけど。
（こういう聞き方だったか覚えていません・・質問の意図が否定的だったのか、純粋な疑問だったのかもわかりません）
Spring Securityは拡張ポイントが沢山あるので、使える。どこかに業務ロジックを実装することになる。
たぶん、UserDetailsServiceかAuthenticationProviderを実装することになると思います。
僕が実プロジェクトでSpring Securityを使った時は、確かに認証処理が一番のキモでした（一番実行される箇所）。そのときは業務ロジックはAuthenticationProviderに実装しました。(手続き的にね・・・)
無理やりにでもSpring Securityの拡張ポイントに押し込めることで何が嬉しいかというと、ユーザー情報の扱いや認可処理、各種フィルタ処理をSpring Securityの枠組みで利用できる点です。
「Spring Security使えない！認証は独自処理でやる！」となると、Spring Securityでやってくれるはずの沢山のことを自分で実装しなくちゃいけなくなります・・(もちろん部分的にはSpring Securityの機能は使えますが)
業務ロジックをこのレイヤーに書きたくない、という趣旨だったんでしょうか。
質問?その２
Spring Securityは拡張性高くないよ！
そ、そうですか・・・おそらくあなたのニーズには合わなかったのでしょうね。自分のニーズに合わないからといって全部を否定しなくとも・・と思いますが。
本当に合わなかったのかな？調査不足の可能性もあり。
質問その３
SpringはJTAに対応している？
しています。org.springframework.transaction.PlatformTransactionManagerの実装としてorg.springframework.transaction.jta.JtaTransactionManagerが用意されています。JavaEEコンテナを使っていれば<tx:jta-transaction-manager />を設定するだけですね。
Tomcatを使っているなら別途JTA実装ライブラリが必要です。今ならAtomikosなのかな。
この辺参照。MyEclipse for Springで作る雛形プロジェクトがAtomikos+JtaTransactionManagerを使っていたと思います。体験版をダウンロードして確認すると良いかもです。
相性問題にお気をつけください！
質問その４
SpringはJMSのメッセージキューを同梱している？
いいえ。メッセージキューは同梱していません。JMS APIのラッパー等が用意されていて、基本的には製品非依存です。ここ参照。
JMS2.0に対応するとちょっと変わるかもです。
質問その５
SpringでHot Reloadって対応しています？
Spring自体は対応していないですが、JRebelという有償ツールを使用すると可能らしいです。 あとは公式サブプロジェクトにもSpring Loadedというのがあり、Hot Reloadっぽいです。 ただ、あまりSpringでHotReload！って聞かないですね。あまり求められていないのかも。
個人的にはHot Reloadにもデメリットはありますし、Hot Reloadがあるからという理由でSeasar技術にこだわるのは、iPhoneが登場したときに「ガラケで十分。iPhoneにはおサイフケータイないし」って言っていた人たちとダブります。
質問その６
JPAってどうです？
個人的には好きですが、日本ではあまり受け入れられないですね。
よく言われるのがマスターメンテなら使える。と。 僕が実案件で使用したときはRESTサービスの構築だったので、たしかに基本的はEntityのCRUDだけでしたねぇ・・・
正規化されてない場合は使わない方が良いです。 特にレガシーテーブルを使ったシステムの機能追加とかには使わないように。 そういうシステムだとやっぱりMyBatisとかSQLマッパーが良いんでしょうね。
あとはカラム数が100超えるようなテーブルばっかりだとつらいと思う。通常Entityを取得する際には全カラムをとってくるので。（自分がつかったときは高々50カラムくらいだったなぁ）
JPAを使う場合はきれいに設計ができる体制が整っていることは必須だと思う。 JPAを否定する人はそういうところが無理だ！と決めつけている感はある。 この辺はまた別途まとめたい。
質問その７
Domaって使われてます？
実例は聞いたことないです・・・ ただ相性は良いと思うので、これから増えていってほしいですね。自分も是非サンプルを作りたい。
JJUG幹事になって初のJJUG CCCでした。裏方作業＋発表で結構大変でしたが、充実感がありました。 実はけっこう準備がぐだぐだだったりしたので、次回は改善していきたいです。
次回の公募は総選挙制にしたらどうだろうか・・・