スライド概要 Springでトランザクションを管理する際は @Transactional を使うことが多いと思います。しかし、このアノテーションによって何が起こっているのかはご存知でしょうか?このセッションでは、初級者向けのトランザクションとは何か・ @Transactional の基本的な使い方から、中上級者向けのSpringによるトランザクション管理の仕組みまで、徹底的に解説します。
![詳解Springトランザクション -初級から上級まで- #jsug | ドクセル](https://cdn-ak-scissors.b.st-hatena.com/image/square/c894868c359739a9030820b08bf626f00512b07e/height=288;version=1;width=512/https%3A%2F%2Fbcdn.docswell.com%2Fpage%2FYJ9N529WJ3.jpg%3Fwidth%3D480)
スライド概要 Springでトランザクションを管理する際は @Transactional を使うことが多いと思います。しかし、このアノテーションによって何が起こっているのかはご存知でしょうか?このセッションでは、初級者向けのトランザクションとは何か・ @Transactional の基本的な使い方から、中上級者向けのSpringによるトランザクション管理の仕組みまで、徹底的に解説します。
概要 Spring BootでMVC関連の処理やログイン関連の処理のテストコードについて、あれこれ試行錯誤しながら書いたので、備忘録としてまとめておきます。 ※ログイン関連の処理については別記事に書いています。 もっといい書き方等ご存知でしたらやさしく教えて頂けるとうれしいです(╹◡╹) ソースコードはGitHubで公開しています。 基本テストコード ログイン処理 読まなくても何とかなる前置き(クリックで開閉します) 昨今、テストコードを書いた方がいい、という話がしばしば耳に入ってきていました。 それなら書いてみるか、と思って調べてみると、大体四則演算レベルのテストで止まってしまっており、実際のアプリでどう書いたらいいの...!? となってしまい、いまいちテストコードを書くのに踏み切れていませんでした。 このままではマズいなと思ったので、お盆休みを生贄に捧げ、Spring Bootでエラー
この記事について 最近(5.4〜6.0)のSpring Securityでは、セキュリティ設定の書き方が大幅に変わりました。その背景と、新しい書き方を紹介します。 非推奨になったものは、将来的には削除される可能性もあるため、なるべく早く新しい書き方に移行することをおすすめします。(既に削除されたものもあります) この記事は、Spring Securityのアーキテクチャの理解(Filter Chain、 AuthenticationManager 、 AccessDecisionManager など)を前提としています。あまり詳しくない方は、まずopengl_8080さんのブログを読むことをおすすめします。 サンプルコード -> https://github.com/MasatoshiTada/spring-security-intro 忙しい人のためのまとめ @Configuration
この資料について JJUG CCC 2018 Spring の表題セッションの発表資料を Qiita にて公開したものです (twitter: #ccc_g4)。 内容は上記のスライドとほぼ同じですので、見やすい方で見ていただければと思います。 Spring Boot とそれ以外のライブラリ Spring Initializr で Spring Boot 一式が動くプロジェクトは簡単に作れる。 しかし、実際の web アプリケーションでは追加でさまざまなライブラリを使いたくなる (世の中や社内のコード資産の活用のため)。 とりあえず build.gradle, pom.xml に dependency を追加すれば動くが... ライブラリを追加によって発生しがちな課題 DI や Configuration の課題: @Autowired 等の DI 機能を活用できていない ライブラリ側に
今回は、Spring Bootのメイン機能の一つであるAutoConfigureの仕組みを紹介したいと思います。 Spring Bootを利用すると、簡単なアプリケーションであれば開発者がBean定義を行わなくてもSpringアプリケーションが作成できてしまいます。これはSpring Bootの最大の特徴ですが、Springアプリケーションを構築する上でBean定義そのものが不要になったというわけではありません。 Spring Bootが登場するまで開発者がコツコツBean定義していた部分を、Spring Bootが提供しているAutoConfigureという仕組みが単に肩代わりしてくれているだけなのです!! 前提バージョン Spring Boot 1.4.1.BUILD-SNAPSHOT (投稿時点のスナップショット) Spring Framework 4.3.3.BUILD-SNAPS
各バージョン 訳あってSpringのバージョンが3.2.8.RELEASEですが、4系の最新版でも問題ないです。 その場合、Spring Test DBUnitのバージョンは、1.3.0が良いです。 Java 1.8.0 update 92 Spring Framework 3.2.8.RELEASE Spring Test DBUnit 1.0.1 DbUnit 2.5.2 H2 Database 1.4.191 JUnit 4.12 背景 Spring + DbUnit + Spring Test DBUnit を使ってDB関連クラスの単体テストを行う場合に、 各開発者の環境やCI環境においてそれぞれの環境でDBを用意するのは大変なので、 インメモリなH2 Databaseを採用することは少なくないと思っています。 <bean id="dataSource" class="org.h2
4月に発売した書籍「Kotlin サーバーサイドプログラミング実践開発」なのですが、この中で途中まで作っていてボツネタにした内容がありました。 gihyo.jp それが「Gradleのマルチプロジェクトでオニオンアーキテクチャを実現する」というものです。 第2部で作成していたbook-managerというアプリケーションは、もともとこれを使って作成していましたが、途中でやめて現在の形になりました。 github.com ボツネタにした理由としては、一回実践で導入してみていくつか微妙な点があったことと、紙面上の説明が複雑になるのでベーシックな内容としては外していいかなと思ったためです。 ただせっかく途中まで作っていたので、試して微妙と感じた点も含めて、今回紹介したいと思います。 サンプルとしてこのbook-managerの内容をマルチプロジェクト化したアプリケーションを使い、オニオンアーキテ
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く