読者です 読者をやめる 読者になる 読者になる

M12i.

学術書・マンガ・アニメ・映画の消費活動とプログラミングについて

『Spring Bootリファレンス・ガイド』より第4部「Spring Boot の重要機能」(2)

Java Spring

前回に引き続き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 MVCSpring Frameworkの核心の一部であり、詳細情報はリファレンス・ドキュメンテーションで参照可能です。Spring MVCについて取り扱ったいくつかのガイドがspring.io/guidesでも参照可能です。

24.1.1 Spring MVC 自動コンフィギュレーション

Spring BootはSpring MVCのために、たいがいのWebアプリケーションでうまく動作する自動コンフィギュレーションの仕組みを提供しています。

自動コンフィギュレーションはSpringフレームワークのデフォルトの動作の上に以下の起動を追加します:

  • ContentNegotiatingViewResolverBeanNameViewResolverビーンの包含
  • WebJars(後述)のサポートも含む、静的リソース提供のサポート
  • ConverterGenericConverterそして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 MVCResourceHttpRequestHandlerクラスによるものです。この挙動は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の自動コンフィギュレーションでは以下のテンプレート・エンジンがサポートされています:

デフォルトの設定でこれらのうち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を登録する場合、当該のFilterERRORディスパッチャとして明示的に登録されている必要があります。例えば:

@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の実装を利用しています。EmbeddedWebApplicationContextWebApplicationContextの特化型であり、単一のEmbeddedServletContainerFactoryビーンを検索することで自身を起動します。たいていの場合、TomcatEmbeddedServletContainerFactoryもしくはJettyEmbeddedServletContainerFactoryが見つかって自動で関連付けられることになります。

[NOTE]あなたはこれらの実装クラスについていつも気にかけていたりする必要はありません。ほとんどのアプリケーションではあなたに変わって自動的に適切なApplicationContextEmbeddedServletContainerFactoryが生成され設定されます。

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のサポートにいくつかの制約が発生します。

  • Tomcatの場合、warパッケージを使用していれば問題ありません。つまり、実行可能warファイルであればうまく動きますし、標準的なコンテナ(Tomcatを含むあらゆるコンテナ)にデプロイすることも可能です。しかし実行可能jarファイルの場合、Tomcatではハード・コードされたファイルのためにうまく動きません。
  • Jettyの場合、今のところ組み込みコンテナとJSPを組み合わせることはできません。

こちらにある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標準APIjavax.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 APIJavaオブジェクトとRDBMSのリレーションとを対応付けることを可能にする標準的なテクノロジーです。spring-boot-starter-data-jpaのPOMはこのテクノロジーを利用するための簡便な方法を提供します。このPOMは次のような重要な依存性を提供しています:

ここではJPAについてより詳しい説明はしません。spring.ioで公開されているガイド‘Accessing Data with JPA’やSpring Data JPAHibernateのリファレンスを参照してみてください。

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”'にその方法が載っています。

26.3.2 Spring Data JPA リポジトリ

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"です。


Spring関連の訳出記事まとめ - M12i.