『Spring Bootリファレンス・ガイド』より第4部「Spring Boot の重要機能」(2)
前回に引き続きSpring Bootのリファレンス・ガイドの第4章「Spring Boot の重要機能」("Part IV. Spring Boot features")から。
今回はSpring MVC関連の話題とJDBC/JPAに関する箇所の訳出。原典は"Spring Boot Reference Guide"(1.1.8.RELEASE版。2014/10/28取得)の"Part IV. Spring Boot features"です。
* * *
24. Webアプリケーションを開発する
Spring BootはWebアプリケーションを開発するのにもってこいのスイートです。TomcatもしくはJettyを組み込んだ自己充足型のHTTPサーバーが簡単に作られます。ほとんどのWebアプリケーションはspring-boot-starter-webモジュールを使用してすばやく構築して起動することができます。
もしSpring BootでWebアプリケーションをつくったことがないのであれば、'Getting started'セクションにあるサンプル・アプリケーション"Hello World!"の手順にしたがって作業してみてください。
24.1 ‘Spring Web MVC framework’について
Spring Web MVCフレームワーク(しばしば単純化され‘Spring MVC’と呼ばれています)は高機能なMVCフレームワークです。Spring MVCは@Controller
もしくは@RestController
で印付けられたビーン〔訳注:コントローラとして機能する〕によりHTTPリクエストを処理します。あなたが作成したコントローラに定義されたメソッドは@RequestMapping
アノテーションによりHTTPリクエストにマッピングされます。
ここに示すのは@RestController
を使用してJSONデータを返す処理を定義する典型的な例です:
@RestController @RequestMapping(value="/users") public class MyRestController { @RequestMapping(value="/{user}", method=RequestMethod.GET) public User getUser(@PathVariable Long user) { // ... } @RequestMapping(value="/{user}/customers", method=RequestMethod.GET) List<Customer> getUserCustomers(@PathVariable Long user) { // ... } @RequestMapping(value="/{user}", method=RequestMethod.DELETE) public User deleteUser(@PathVariable Long user) { // ... } }
Spring MVCはSpring Frameworkの核心の一部であり、詳細情報はリファレンス・ドキュメンテーションで参照可能です。Spring MVCについて取り扱ったいくつかのガイドがspring.io/guidesでも参照可能です。
24.1.1 Spring MVC 自動コンフィギュレーション
Spring BootはSpring MVCのために、たいがいのWebアプリケーションでうまく動作する自動コンフィギュレーションの仕組みを提供しています。
自動コンフィギュレーションはSpringフレームワークのデフォルトの動作の上に以下の起動を追加します:
ContentNegotiatingViewResolver
とBeanNameViewResolver
ビーンの包含- WebJars(後述)のサポートも含む、静的リソース提供のサポート
Converter
、GenericConverter
そしてFormatter
ビーンの自動的な登録HttpMessageConverters
(後述)のサポートMessageCodeResolver
(後述)の自動的な登録- 静的なindex.htmlのサポート
- 独自ファビコンのサポート
Spring MVCを完全にコントロールしたい場合は、@Configuration
を付与したクラスに@EnableWebMvc
アノテーションも付与することで可能です。Spring Boot MVCの機能を維持し、しかもそこに追加の設定(インターセプタ、フォーマッタ、ヴュー・コントローラなどなど)を施したい場合は、@EnableWebMvc
を使用せず、WebMvcConfigurerAdapter
の@Bean
クラスを定義してください。
24.1.2 HttpMessageConverters
Spring MVCではHTTPリクエストとレスポンスを変換するのにHttpMessageConverter
インターフェースを使用しています。実用性を考慮してインターフェースのデフォルト実装が用意されています。これにより例えば、Object
インスタンスは自動的にJSON(Jacksonライブラリが使用されます)やXML(JAXBが使用されます)に変換されます。
別のコンバータと追加したり、デフォルトのコンバータをカスタマイズする必要がある場合、Spring Bootが提供する HttpMessageConverters
クラスが利用できます:
import org.springframework.boot.autoconfigure.web.HttpMessageConverters; import org.springframework.context.annotation.*; import org.springframework.http.converter.*; @Configuration public class MyConfiguration { @Bean public HttpMessageConverters customConverters() { HttpMessageConverter<?> additional = ... HttpMessageConverter<?> another = ... return new HttpMessageConverters(additional, another); } }
24.1.3 MessageCodesResolver
Spring MVCはバインドされたエラー情報からエラー・メッセージを表示するにあたりエラー・コードを生成するストラテジを持っており、このために用意されているのがMessageCodesResolver
です。spring.mvc.message-codes-resolver.format
プロパティにPREFIX_ERROR_CODE
もしくはPOSTFIX_ERROR_CODE
(詳しくは列挙型DefaultMessageCodesResolver.Format
を参照してください)が設定されている場合、Spring BootはMessageCodesResolver
のデフォルト実装を生成します。
24.1.4 静的コンテンツ
デフォルトでは、Spring Bootは静的コンテンツをクラスパス内の/static(もしくは /public、/resources、/META-INF/resources)ディレクトリもしくは、ServletContext
のrootから取得してクライアントに返します。これはSpring MVCのResourceHttpRequestHandler
クラスによるものです。この挙動はWebMvcConfigurerAdapter
を作成して、addResourceHandlers
メソッドをオーバーライドすることで変更可能です。
スタンド・アローンのWebアプリケーションでは、コンテナ由来のデフォルト・サーブレットも有効です。もしSpringが供給すべき静的コンテンツを決定できない場合、代わりにServletContext
のrootから静的コンテンツを供給します。たいていの場合、これは起こりえないことです(デフォルトのMVCの設定を変更しない限り)。というのもSpringフレームワークはDispatcherServlet
を通じてあらゆるリクエストを処理することが可能だからです。
上記の標準的な静的ファイル格納場所に対して、Webjarsコンテンツは特殊ケースになります。/webjars/**の形式のパスで参照されるリソースはすべて、当該リソースがWebjarsフォーマットでパッケージされていれば、jarファイルから供給されます。
[NOTE]あなたのアプリケーションがjarとしてパッケージされるものである場合はsrc/main/webappディレクトリを使用しないでください。このディレクトリは標準的なものですが、warパッケージにおいてのみ利用されるものであり、jarパッケージを生成する場合ほとんどのツールは何らの通知もなくこのディレクトリを無視するからです。
24.1.5 テンプレート・エンジン
REST Webサービス同様、動的HTMLコンテンツ提供のためにもSpring MVCは使用できます。Spring MVCはVelocity、FreeMarkerそしてJSPを含むさまざまなテンプレート・エンジンをサポートしています。その他のエンジンの多くもSpring MVCと統合するためのAPIを提供しています。
Spring Bootの自動コンフィギュレーションでは以下のテンプレート・エンジンがサポートされています:
- FreeMarker
- Groovy
- Thymeleaf
- Velocity
デフォルトの設定でこれらのうち1つを使用する場合、テンプレートはsrc/main/resources/templatesディレクトリから自動で読み込まれます。
可能ならJSPの使用は避けたほうがいいでしょう。組み込みのサーブレット・コンテナとともにJSPを使用する場合、いくつかの既知の制約〔後述〕があります。
24.1.6 エラー処理
Spring Bootは/errorマッピングの機能を提供しています。デフォルトで、すべてのエラーは賢明な方法でハンドリングされ、サーブレット・コンテナの‘グローバルな’エラー・ページへと結び付けられます。機械クライアント〔訳注:ようするにXmlHttpRequestであればSOAPリクエストであれ、いずれにせよ非・人間的な〕に対しては、エラーの詳細、HTTPステータス、そして例外メッセージを伴うJSONレスポンスを返します。ブラウザ・クライアントに対しては、同じ内容がHTML形式でレンダリングされた‘飾り気のない’〔whitelabel〕エラー・ページが表示されます(この動作をカスタマイズするには単に‘error’に対応するView
〔View that resolves to ‘error’〕を作成するだけです)。デフォルトの動作を完全に置き換えてしまう場合は、ErrorController
インターフェースを実装してビーン定義を登録するか、あるいは単にErrorAttributes
型のビーン──既存のメカニズムを利用するがコンテンツを置き換えてしまう──を作成するかします。
何らかの条件次第でより特別なエラー・ページを表示したいという場合には、組み込みのサーブレット・コンテナがサポートするエラー・ハンドリングをカスタマイズするための統一されたJava DSLを利用します〔訳注:これを読むとようするにサーブレット・コンテナ次第だと言っているようにも見えるのですが、実際にはSpring Bootがコンテナの挙動をカスタマイズするための単一のAPIを提供しており、これを使ってカスタマイズをすればよい、ということです〕。例えば:
@Bean public EmbeddedServletContainerCustomizer containerCustomizer(){ return new MyCustomizer(); } // ... private static class MyCustomizer implements EmbeddedServletContainerCustomizer { @Override public void customize(ConfigurableEmbeddedServletContainer container) { container.addErrorPages(new ErrorPage(HttpStatus.BAD_REQUEST, "/400")); } }
もちろん@ExceptionHandler
アノテーションで印付けられたメソッドや@ControllerAdvice
アノテーションで定義されたAOPアドバイスなど、もともとSpring MVCが提供している機能も使用できます。ErrorController
はハンドリングされていない例外を捕まえて処理します。
注意:最終的にはFilter
(JerseyやWicketのような非・SpringのWebフレームワークにあるような)で処理されることになるパスとともにErrorPage
を登録する場合、当該のFilter
はERROR
ディスパッチャとして明示的に登録されている必要があります。例えば:
@Bean public FilterRegistrationBean myFilter() { FilterRegistrationBean registration = new FilterRegistrationBean(); registration.setFilter(new MyFilter()); ... registration.setDispatcherTypes(EnumSet.allOf(DispatcherType.class)); return registration; }
デフォルトのFilterRegistrationBean
には、ERROR
ディスパッチャ・タイプは含まれません。)
アプリケーション・サーバにおけるエラー・ハンドリング
(興味がないのでパス)
24.2 組み込みサーブレット・コンテナ・サポート
Spring Bootは組み込みのTomcatサーバとJettyサーバの機能にアクセスするためのサポートを提供しています。完全に設定の済んだインスタンスを得るのに、ほとんどの開発者は適切な‘Starter POM’を使用するだけで済みます。TomcatもJettyもデフォルトでは8080ポートでHTTPリクエストを受け付けます。
24.2.1 サーブレットとフィルター
組み込みサーブレット・コンテナを利用している場合、サーブレットとフィルターをSpringビーンとして直接登録することができます。この機能はコンフィギュレーションの最中にapplication.propertiesで定義された値を参照したいときにとくに便利です。
デフォルトでは、コンテキスト〔訳注:サーブレット・コンテキストではなくSpringのアプリケーション・コンテキストを指す〕に単一のサーブレットしか存在しなければ、そのサーブレットは/にマッピングされることになります。複数のサーブレットのビーンが存在した場合、ビーンの名前がパスの接頭辞として使用されます。フィルターは/*にマッピングされます。
規約ベースのマッピング〔訳注:上述のビーン名称によるマッピングのこと〕が柔軟性に欠けるという場合には、マッピングの制御のためにServletRegistrationBean
クラスとFilterRegistrationBean
クラスを利用することができます。あるいはまたServletContextInitializer
インターフェースを実装することで直接アイテムを登録してしまうこともできます。
24.2.2 EmbeddedWebApplicationContext について
舞台の裏側では、組み込みサーブレット・コンテナ・サポートのため、Spring Bootは新しいApplicationContext
の実装を利用しています。EmbeddedWebApplicationContext
はWebApplicationContext
の特化型であり、単一のEmbeddedServletContainerFactory
ビーンを検索することで自身を起動します。たいていの場合、TomcatEmbeddedServletContainerFactory
もしくはJettyEmbeddedServletContainerFactory
が見つかって自動で関連付けられることになります。
[NOTE]あなたはこれらの実装クラスについていつも気にかけていたりする必要はありません。ほとんどのアプリケーションではあなたに変わって自動的に適切なApplicationContext
とEmbeddedServletContainerFactory
が生成され設定されます。
24.2.3 組み込みサーブレット・コンテナをカスタマイズする
一般的なサーブレット・コンテナの設定はEnvironment
に登録されたプロパティを通じて行うことができます。 たいていはapplication.propertiesファイルにこれらのプロパティを定義することになるでしょう。
一般的なサーバー設定としては次のものが含まれます:
server.port
— HTTPリクエストの到着を待ち受けるポートserver.address
— バインドされるネットワーク・インターゲースのアドレスserver.sessionTimeout
—セッションタイム・アウト
完全なリストについてはServerProperties
のドキュメンテーションを参照してください。
プログラム・コードからのカスタマイズ
組み込みサーブレット・コンテナをプログラム・コードからカスタマイズする必要がある場合は、EmbeddedServletContainerCustomizer
インターフェースを実装したビーンを登録します。EmbeddedServletContainerCustomizer
を通じて、カスタマイズのために非常にたくさんのセッター・メソッドを持つConfigurableEmbeddedServletContainer
にアクセスすることが可能です。
import org.springframework.boot.context.embedded.*; import org.springframework.stereotype.Component; @Component public class CustomizationBean implements EmbeddedServletContainerCustomizer { @Override public void customize(ConfigurableEmbeddedServletContainer container) { container.setPort(9000); } }
ConfigurableEmbeddedServletContainerを直接カスタマイズする
上述のカスタマイズ方法では制約が大きすぎるという場合、TomcatEmbeddedServletContainerFactory
もしくはJettyEmbeddedServletContainerFactory
といういずれかのビーンをあなた自身で実装して登録するという方法をとることができます。
@Bean public EmbeddedServletContainerFactory servletContainer() { TomcatEmbeddedServletContainerFactory factory = new TomcatEmbeddedServletContainerFactory(); factory.setPort(9000); factory.setSessionTimeout(10, TimeUnit.MINUTES); factory.addErrorPages(new ErrorPage(HttpStatus.404, "/notfound.html"); return factory; }
多くのオプションのためにセッター・メソッドが提供されています。より特別なことをしたいというニーズに応えるために、いくつかのprotected
メソッド‘フック’も提供されています。さらに詳しい情報については当該クラスのソースコード・ドキュメンテーションを参照してください。
24.2.4 JSPにまつわる制約事項
組み込みのサーブレット・コンテナを使用してSpring Bootアプリケーションを実行している場合(しかも実行可能アーカイブとしてアプリケーションがパッケージングされている場合)、JSPのサポートにいくつかの制約が発生します。
25. セキュリティ
Spring Securityのモジュールがクラスパス上にある場合、すべてのHTTPアクセスについてデフォルトでBASIC認証による保護が有効になります。あなたの望む設定情報とともに@EnableGlobalMethodSecurity
アノテーションを追加することで、メソッド・レベルのセキュリティ設定が可能になります。その他の情報はSpring Securityのリファレンスで得られるでしょう。
デフォルトのAuthenticationManager
〔訳注:Spring Securityが提供する認証メカニズムの中核にあるオブジェクト〕では認証をパスできるのはただひとりのユーザだけです(ユーザ名は固定の‘user’とパスワードはランダムに生成され、アプリケーション起動時のINFOレベル・ログに出力されます)。
Using default security password: 78fa095d-3f4c-48b1-ad50-e24c31d5cf35
security.user.password
プロパティによりこのパスワードは変更できます。このプロパティをはじめ有用なプロパティ群はSecurityProperties
("security"という接頭辞の付くプロパティ群)により外部化〔訳注:あるいは、パラメータ化〕されています。
デフォルトのセキュリティ・コンフィギュレーションはSecurityAutoConfiguration
とそこからインポートされている各種のクラスにおいて実装されています(SpringBootWebSecurityConfiguration
はWebアプリケーションのセキュリティのため、またAuthenticationManagerConfiguration
は非・Webアプリケーションに関連する認証設定のために用意されています)。
@EnableWebSecurity
をビーンに追加することで、Spring Bootが提供するWebアプリケーションのデフォルト設定を完全にOFFにすることができます。(例えばフォーム・ベース認証の機能を追加するなど)デフォルトの設定をカスタマイズしたい場合は、外部化されたプロパティやWebConfigurerAdapter
型のビーンを使用します。一般的な使用ケースについて学んでもらうため、Spring Bootのサンプル・アプリケーションのなかにはいくつかSpring Securityを利用したものが含まれています。
デフォルトの設定で利用可能な基本的機能として次のものがあります:
- イン・メモリのデータベースとシングル・ユーザのログインを可能にする
AuthenticationManager
(このユーザのプロパティにアクセスするにはSecurityProperties.User
を使用します) - 一般的な静的リソースの格納場所を指すために認証機構から無視される(非・セキュアな)パス(/css/**、/js/**、/images/** そして **/favicon.ico)
- すべてのエンドポイントを対象としたBASIC認証
- Springフレームワークの
ApplicationEventPublisher
に対するセキュリティ関連イベントの通知(認証の成功と失敗、そして拒絶されたアクセス) - Spring Securityがデフォルトで提供する一般的なロー・レベルの機能(HSTS、XSS対策、CSRF対策、キャッシング)
上記のいずれも外部化されたプロパティ(security.*
系の)を使用してON・OFFしたり、動作変更をしたりすることが可能です。 他の自動設定されたいずれの機能についても影響を与えないかたちで特定のアクセス・ルールを上書きしたい場合、@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
アノテーションを伴うWebConfigurerAdapter
型のビーンを作成します。
Actuator〔訳注:システムの状態を確認するためのエンドポイントを追加してくれるモジュール〕も使用している場合、次のこともわかるでしょう:
- アプリケーション自体の他のエンドポイントが非・セキュアな状態であっても管理用エンドポイントについてだけはセキュアな状態に保たれます
- セキュリティ・イベントは
AuditEvents
に変換され、AuditService
に対して通知されます。 - デフォルト・ユーザにはUSERロールだけでなくADMINロールも付与されます。
Actuatorのセキュリティ機能も外部化されたプロパティ(management.security.*
系の)で変更できます。アプリケーションのアクセス・ルールを上書きするためWebConfigurerAdapter
型のビーンを作成する際、Actuatorのアクセス・ルールを上書きしたくないという場合は@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)
アノテーションを、反対にActuatorのアクセス・ルールを上書きしたい場合は@Order(ManagementServerProperties.ACCESS_OVERRIDE_ORDER)
アノテーションを使用します。
26. SQLデータベースを利用する
SpringフレームワークはSQLデータベースを利用するための拡張可能なサポートを提供しています。その対象には、JdbcTemplate
を使用した直接のJDBCアクセスから、Hibernateのような完璧なORマッピング技術を利用したアクセスまでが含まれます。一方、Spring Dataは〔ユーザが用意した〕インターフェースから自動的にRepository
実装を生成し、メソッド名からクエリーを自動導出するなど、より高度な機能を提供します。
26.1 DataSource を設定する
Java標準APIのjavax.sql.DataSource
インターフェースはデータベース接続を利用するための標準的なメソッドを提供しています。伝統的に、データベース接続を確立するためのいくつかの認証情報を伴ったURLを使用します。
26.1.1 組み込みのデータベース・サポート
イン・メモリの組み込みデータベースを使用するアプリケーションを開発するに便利な機能です。言うまでもなくイン・メモリのデータベースは永続的なストレージとしては機能しません。データはアプリケーションの起動のたびにつくってやる必要があり、アプリケーションの終了とともに消滅してしまいます。
[NOTE]‘How-to’セクションでデータベースをイニシャライズする方法が載っています。
Spring Bootでは組み込みデータベースとしてH2、HSQLそしてDerbyデータベースが自動設定可能です。あなたはいかなる接続URLも指定してやる必要がありません。ビルドの依存関係にそのデータベースを追加し、必要なときに使用するだけです、
例えば、典型的なPOMの依存性記述は次のようになるでしょう:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-jpa</artifactId> </dependency> <dependency> <groupId>org.hsqldb</groupId> <artifactId>hsqldb</artifactId> <scope>runtime</scope> </dependency>
[NOTE]組み込みのデータベースを自動設定させるためにはspring-jdbcの追加も必要です。上記の例ではspring-boot-starter-data-jpaを依存性に追加することで、推移的にspring-jdbcの依存性も追加されています〔訳注:spring-boot-starter-data-jpaがspring-jdbcに依存しているため、明示的に指定する必要がないということ〕。
26.1.2 本番稼動用データベースへの接続
プーリングされたDataSource
を使用するかたちで本番稼動用データベース接続を自動設定させることもできます。ここに示すのは、特定の実装が選ばれる際に使用されるアルゴリズムです:
- パフォーマンスと並列性を考慮するとTomcatのプーリングされた
DataSource
が好ましい。よって、もしそれが可能ならいつでもそれを選ぶ。 - もしcommons-dbcpが可能ならそれを選ぶ。ただし本番稼動ためにはお薦めしない。
もしあなたが‘starter POMs’ で指定されたspring-boot-starter-jdbc もしくは spring-boot-starter-data-jpaを使用しているのであれば、自動的にtomcat-jdbcが選択される。
[NOTE]手動設定を行うことでその他のコネクション・プールも利用可能です。あなた自身で独自のDataSource
ビーンを定義している場合、自動コンフィギュレーションは行われません。
DataSource
設定はspring.datasource.*
系の外部コンフィギュレーション・プロパティによって制御されます。例えば、application.propertiesファイルの中で以下ような一連の定義をします:
spring.datasource.url=jdbc:mysql://localhost/test spring.datasource.username=dbuser spring.datasource.password=dbpass spring.datasource.driverClassName=com.mysql.jdbc.Driver
サポートされているオプションについて、詳しくはDataSourceProperties
のドキュメンテーションを参照してください。
[NOTE]プーリングされたDataSource
を生成するためには、適切なドライバー・クラスが利用可能であることを確認できなくてはなりません。この点を先にチェックしておかなく必要があります。言い換えれば、spring.datasource.driverClassName=com.mysql.jdbc.Driver
というプロパティを定義するなら、このクラスが実際にロード可能である必要があるということです。
26.2 JdbcTemplate を利用する
Springの提供するJdbcTemplate
クラスとNamedParameterJdbcTemplate
クラスは自動設定されます。@Autowire
アノテーションを利用して、あなたの定義したビーンのフィールドに設定することができます:
import org.springframework.beans.factory.annotation.Autowired; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.stereotype.Component; @Component public class MyBean { private final JdbcTemplate jdbcTemplate; @Autowired public MyBean(JdbcTemplate jdbcTemplate) { this.jdbcTemplate = jdbcTemplate; } // ... }
26.3 JPAと‘Spring Data’
Java Persistece APIはJavaオブジェクトとRDBMSのリレーションとを対応付けることを可能にする標準的なテクノロジーです。spring-boot-starter-data-jpaのPOMはこのテクノロジーを利用するための簡便な方法を提供します。このPOMは次のような重要な依存性を提供しています:
- Hibernate — もっとも人気のあるJPA実装のひとつ
- Spring Data JPA — JPAベースのリポジトリを実装するのを平易なものとするためのAPI
- Spring ORMs — Springフレームワークが提供するORマッピング・サポート
ここではJPAについてより詳しい説明はしません。spring.ioで公開されているガイド‘Accessing Data with JPA’やSpring Data JPA、Hibernateのリファレンスを参照してみてください。
26.3.1 エンティティ・クラス
伝統的に、JPAの‘Entity’クラスはpersistence.xmlファイルのなかで定義されます。しかしSpring Bootを使用している場合、このファイルによる設定は不要です。代わりに、‘Entityスキャニング’を使用します。デフォルトでは、メインのコンフィギュレーション・クラス(@EnableAutoConfiguration
アノテーションが付与されている)の属するパッケージとそのサブパッケージすべてがスキャニング対象です。
@Entity
アノテーション、@Embeddable
アノテーション、そして@MappedSuperclass
アノテーションが付与されたすべてのクラスが‘Entity’クラスと見做されます。典型的な‘Entity’クラスは以下のようなものです:
package com.example.myapp.domain; import java.io.Serializable; import javax.persistence.*; @Entity public class City implements Serializable { @Id @GeneratedValue private Long id; @Column(nullable = false) private String name; @Column(nullable = false) private String state; // ... additional members, often include @OneToMany mappings protected City() { // no-args constructor required by JPA spec // this one is protected since it shouldn't be used directly } public City(String name, String state) { this.name = name; this.country = country; } public String getName() { return this.name; } public String getState() { return this.state; } // ... etc }
[NOTE]Entityスキャニングの対象となる場所は@EntityScan
アノテーションによってカスタマイズ可能です。'Section 62.4, “Separate @Entity definitions from Spring configuration”'にその方法が載っています。
Spring Data JPAリポジトリはアプリケーションのデータ・アクセスを定義するためのインターフェースです。JPAクエリはメソッド名から自動導出されます。例えば、所定の状態を持つ都市〔City〕を検索するために、CityRepository
インターフェースにfindAllByState(String state)
メソッドを宣言します。
Spring DataのQuery
アノテーションをメソッドに付与することで、より複雑なクエリを実行することが可能です。
たいていSpring DataリポジトリはRepository
もしくは CrudRepository
インターフェースを拡張して作られます。自動コンフィギュレーションを使用している場合、リポジトリはメインのコンフィギュレーション・クラス(@EnableAutoConfiguration
アノテーションが付与されている)の属するパッケージとそのサブパッケージから検索されます。
ここに示すのは典型的なSpring Dataリポジトリの例です:
package com.example.myapp.domain; import org.springframework.data.domain.*; import org.springframework.data.repository.*; public interface CityRepository extends Repository<City, Long> { Page<City> findAll(Pageable pageable); City findByNameAndCountryAllIgnoringCase(String name, String country); }
[NOTE]ここで解説しているのはSpring Data JPAのほんの表層についてだけだけです。より完全な情報についてはリファレンスを参照してください。
26.3.3 JPAデータベースのCREATEとDROP
デフォルトではJPAデータベースは組み込みデータベース(H2、HSQLあるいはDerby)を利用している場合のみ自動的に作成されます。 このJPAに関するの挙動はspring.jpa.*
系のプロパティを用いることで明示的に設定することができます。例えば、テーブルのCREATEとDROPを自動実行させたい場合application.propertiesに次の項目を追記します:
spring.jpa.hibernate.ddl-auto=create-drop
[NOTE]Hibernateでは同じ目的のために独自の内部的なプロパティhibernate.hbm2ddl.auto
を用意しています(このことは覚えておいたほうがいいでしょう)。spring.jpa.properties.*
という接頭辞をつけることで、その他のHibernate固有のプロパティとととに、この独自のプロパティを設定することが可能です(この接頭辞はエンティティ・マネージャに登録される前に取り除かれます)。例えば:
spring.jpa.properties.hibernate.globally_quoted_identifiers=true
このようにプロパティを宣言すると、Hibernateのエンティティ・マネージャにはhibernate.globally_quoted_identifiers
という名前で値が渡されます。
デフォルトでは、DDL実行(もしくはバリデーション)はApplicationContext
が起動するまで待機させられます。プロパティのなかにはspring.jpa.generate-ddl
というフラグもありますが、Hibernateの自動コンフィギュレーションが有効な場合は使用されません〔訳注:機能しないというよりは慣習的にそうされている、という意味らしい〕。というのも、ddl-auto
プロパティのほうがより緻密な設定をできるからです。
27. NoSQLテクノロジーを利用する
(以降のテーマは興味がないのでパス)
* * *
ここまでで個人的興味は満足してしまったのでいったん終了です。原典は"Spring Boot Reference Guide"(1.1.8.RELEASE版。2014/10/28取得)の"Part IV. Spring Boot features"です。