try-finallyでのリソースクローズ tryブロックの中で何らかのリソース（InputStream、OutputStream、BufferedReader等）を扱う場合、Java7以前はfinallyブロックでcloseメソッドを呼び出すことで、tryブロック内の処理が正常終了したか異常終了したかに関わらずリソースが確実に閉じられることを保証していました。以下のような形です。 protected void copy(String src, String dest) throws IOException { InputStream in = new FileInputStream(src); try { OutputStream out = new FileOutputStream(dest); try { byte[] buf = new byte[100]; int n; whil

RESTful APIのリソース設計で述べた通り、何をリソースとするかを決めたらそのリソースを識別するURIを検討する必要がある。 エンドポイントとは何か エンドポイントとはAPIにアクセスするためのURIのこと。例えば、QiitaのAPIで自分の情報を取得する時のエンドポイントは以下となる。 http://qiita.com/api/v2/users/nagaokakenichi 似たような言葉に「エントリポイント」というものがある。エントリポイントとはプログラムやサブルーチンの実行を開始する場所のこと。 Qiita視点で考えると、 http://qiita.com/api/v2/users/nagaokakenichi を参照されることでプログラムが開始されるので、Qiitaからすると上記URIはエントリポイントとなる。 つまり、エンドポイントはAPIにアクセスする側からの、エントリポ

Springでは、Controller個別で例外をハンドリングする方法と、Controllerを横断して例外をハンドリングする方法の2通りのハンドリング方法が存在する。ここでは、RestControllerでのハンドリングを例にしてやってみる。 Controller個別で例外をハンドリングする Controller個別で例外をハンドリングする場合、Controllerクラス内にハンドリング用のメソッドを作成する。このメソッドには@ExceptionHandlerアノテーションを付与する。そうすることでそのControllerクラス内で発生した例外に対する設定を行うことができる。 @RestController @RequestMapping("api/customers") public class CustomerRestController { @Autowired CustomerS

@NotBlank、@NotEmpty、@NotNullの挙動の違いをSpring Boot + Thymeleafで整理するJavaspringjavax.validationThymeleafSpringBoot やりたいこと JSR-303 Bean Validationの挙動がよく分からず、現場で混乱を招いたので整理してみます。具体的には以下のアノテーションです。 ・javax.validation.constraints.NotBlank (@NotBlank) ・javax.validation.constraints.NotEmpty (@NotEmpty) ・javax.validation.constraints.NotNull (@NotNull) 結論 ※タブ以外のエスケープシーケンスは検証していませんが多分タブと同じ挙動になると思っています（多分） 全て全角スペース

初歩的な内容になりますが、Spring Bootを使って開発していると「No qualifying bean of type・・・・」ってエラーを見かけることがあります。だいたいログの内容はこんな感じです。 Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [com.example.domain.repository.CustomerRepository] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {} インスタンスが見つ