JMockit の部分モックを試してみる。このあたりの API はバージョンによって変更や削除となることがあるため要注意。ちなみに今回試したバージョンは以下。
メソッドをモック化する場合は、Expectations の中でモック化したいメソッドを登録する。登録していないメソッドはオリジナルのメソッドが呼び出される。
Expectations の引数にクラスを指定する場合、以降で生成されるそのクラスのインスタンスがモック化される。Expectations の引数にインスタンスを指定する場合、そのインスタンスのみモック化される。
昔は、@Mock("method()") とか書けたようだが、今は使えない模様。
普段、Markdown エディタとして使っている Atom がどうにも重たい。起動が重たいのはしょうがないにしても普通に文字を入力したいときに固まったりするし。
そこで、Atom よりは軽量と噂の Visual Studio Code に乗り換えようかと。標準で Emmet が使えるし。
現在のバージョンは v1.9.1 の模様。とりあえずインストール。
これまで Atom を使っていたからなのか、UI が日本語だと見た目にもっさり感がある。
Configure Language を実行する{ "locale":"en-US" } を設定するその他の設定。
{ "editor.fontSize": 13, "editor.fontFamily": "MeiryoKe_Gothic", "editor.tabSize": 2, "editor.renderWhitespace": "boundary" }
※等幅メイリオについてはこちら
※"editor.renderWhitespace":"boundary" : 単語間の半角スペースを表示しない
※プロキシ環境の場合は "http.proxy" を設定
(2017/02/28 追記)
Atom では任意のフォルダを Project Folder として登録することができる。
で、普段利用するフォルダをいくつか登録しておいて、フォルダツリーから開きたいファイルを選択するような感じで使っていた。
Visual Studio Code にも EXPLORER でフォルダツリーを表示できるが、Atom のように任意のフォルダを複数登録することはできない模様。
というわけで、あるフォルダのファイルを手早く開きたいときは Ctrl + o でファイルを開くようにしている。
(2017/04/17 追記)
Visual Studio Code で JSON をフォーマットするショートカットは Alt+Shift+F だが、minify ができない。というわけで、以下の拡張機能をインストールする。
JSON Tools - Visual Studio Marketplace
Alt+MShift+Alt+Mjava.util.zip.ZipOutputStream による ZIP アーカイブについて調べてたら、以下のようなコードを見かけました。(適当に抜粋してます)
単純に、ディレクトリ配下のファイルを commons-io で取得して、ZIP にアーカイブするコードです。これ自体は正しく動作するし、目的通りに ZIP ファイルが生成されます。
しかし、呼び出し元が以下のような感じだったら。
archive(dirPath);
FileUtils.deleteDirectory(new File(dirPath));
要するに、ZIP ファイルを生成したあと、もとのディレクトリを削除するような場合。このとき、FileUtils#deleteDirectory でエラーが発生します。
java.io.IOException: Unable to delete file: ...
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2192)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1585)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1467)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2183)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1585)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1467)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2183)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1585)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1467)
at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2183)
at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1585)
at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1467)
...
冒頭のコードだと、writeZipEntry メソッドに File オブジェクトの配列を渡して、同じ InputStream の参照でそれぞれのファイルを読み込んでいます。最後に finally で InputStream を close していますが、最後に処理したファイルのストリームしか close されていないのではないかと推測しています。そのため、後続のディレクトリの削除処理でエラーが発生しているのではないか、というわけです。(自信はない…)
冒頭のコードを以下のように変更すると、先のエラーは発生しなくなります。
要するに、処理するファイルごとに writeZipEntry メソッドを呼び出して、毎回 InputStream を close するようにします。
java.io.InputStream は複数のファイル読み込みで共有せず、ファイル読み込みごとに close すること。
ちなみに冒頭のコードですが、writeZipEntry メソッドの最後で System#gc を呼び出すとエラーが発生しなくなります。うーむ…。
今回、Spring Boot + Spring Batch + Java 6 でバッチを実装する機会があったので、もろもろを備忘録としてまとめる。
Spring Tool Suite v3.8.3 を使用。Spring Starter Project からプロジェクトを作成する。
Dependencies で Batch をチェックしてプロジェクトを作成すると、spring-boot-starter-batch の依存が追加される。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-batch</artifactId> </dependency>
プロジェクトを作成して、Run Spring Boot App すると以下のエラーが出る。
... nested exception is java.lang.UnsupportedClassVersionError: org/apache/tomcat/jdbc/pool/DataSource : Unsupported major.minor version 51.0
Tomcat JDBC が Java 6 に対応していない模様。今回、Tomcat やデータベースを使う予定がなかったので、思い切って Tomcat JDBC を依存から除外する。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-batch</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-jdbc</artifactId> </exclusion> </exclusions> </dependency>
とりあえず、Java 6 で Spring Boot + Spring Batch が動作することを確認。
今回は割とシンプルなアプリケーションだったので、Tasklet のみで構成。main メソッドからの流れは基本的に本家のクイックスタートの通り。> Spring Batch
今回、src/main/resources 下の application.properties の他に、エンドユーザが設定するプロパティファイルとして application-env.properties を用意しました。(アプリ内部で利用するプロパティとエンドユーザが設定するプロパティをファイルとして分割しようと思って)
application-env.properties は config ディレクトリに配置して、jar を実行するときに -Dspring.config.location でプロパティファイルのパスを指定すれば読み込める模様。尚、Linux 環境では --spring.config.location なので注意。これで30分くらいハマった…。
java -jar batch.jar -Dspring.config.location=config/application-env.properties
-Dspring.config.location で外部のプロパティファイルを指定したとき、クラスパス上の application.properties は読み込まれるのか不安でしたが、普通に読み込めました。このあたりは別エントリにまとめました。
Spring Boot で複数の @ConfigurationProperties のプロパティを読み込む - kntmr-blog
プロパティは @ConfigurationProperties を付けた Bean 経由で読み込む。@ConfigurationProperties は、カンマ区切りのプロパティを自動的に List<T> に格納してくれたり、Bean Validation と組み合わせてプロパティをチェックできるので便利。
以下の依存を追加。(@NotBlank とかを使おうとすると、STS が追加してくれる)
<dependency> <groupId>javax.validation</groupId> <artifactId>validation-api</artifactId> <version>1.1.0.Final</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency>
@NotNull は javax.validation.constraints パッケージで提供されているアノテーション。@NotBlank, @NotEmpty は Hibernate Validator が提供するアノテーション。それぞれのおおまかな違いは以下を参考にさせていただきました。
@NotNull/@NotEmpty/@NotBlankの違い - 見習いプログラミング日記
Hibernate Validator のバリデーションメッセージは、デフォルトでは「may not be empty」のような英語メッセージとなる。今回、バリデーションメッセージを日本語化するために ValidationMessages.properties を追加したが、ログに出力されるメッセージが文字化ける…。アノテーションの message 属性に直接日本語を書くと問題ないんだけど。
で、ソースコードに直接メッセージを書きたくなかったのと、「may not be empty」でもまぁ問題ないかなということで、バリデーションメッセージの日本語化は諦めることに。
ロギングは Logback を使う。Logbackを使う場合は src/main/resources 配下に logback-spring.xml を配置する。今回は、コンソールとファイルに同じ内容を出力して、ファイルサイズでローテートするようにしている。
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE logback> <configuration> <include resource="org/springframework/boot/logging/logback/defaults.xml" /> <include resource="org/springframework/boot/logging/logback/console-appender.xml" /> <!--<include resource="org/springframework/boot/logging/logback/file-appender.xml" />--> <property name="LOG_FILE" value="../logs/batch.log" /> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${LOG_FILE}</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>${LOG_FILE}.%i</fileNamePattern> <minIndex>1</minIndex> <maxIndex>5</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>100KB</maxFileSize> </triggeringPolicy> <encoder> <pattern>${FILE_LOG_PATTERN}</pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="CONSOLE" /> <appender-ref ref="FILE" /> </root> </configuration>
メッセージプロパティを使う場合は、src/main/resources の application.properties に以下の設定を追加する。
spring.messages.basename=messages spring.messages.cache-seconds=-1 spring.messages.encoding=UTF-8
ソースコードからは MessageSource クラス経由で messages.properties のメッセージを取得する。
// MessageSource クラスを DI @Autowired private MessageSource messageSource; // メッセージを取得 messageSource.getMessage(code, args, Locale.JAPAN);
今回、あるディレクトリ配下のファイルを読み込んでごにょごにょする、みたいな要件がありました。Java 7 以降であれば、Files クラスとか Paths クラスとか何かと便利な API が使えていいんですが、今回は如何せん Java 6 …。というわけで、Apache Commons IO 2.3 を使う。
<dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>2.3</version> </dependency>
あと、やっぱり try-with-resources が使えないのが地味にツライ。
パッケージングは mvn package するだけ。
今回、Spring Batch で作成した jar をシェルスクリプトからキックして、RETVAL=$? でステータスコードを取得する想定でした。
当初、StepContribution#setExitStatus メソッドに ExitStatus.COMPLETED or ExitStatus.FAILED を渡して正常終了か異常終了を判別してみたものの、異常終了の場合でもステータスコードが 0 になる…。
// 正常終了 contribution.setExitStatus(ExitStatus.COMPLETED); // 異常終了 contribution.setExitStatus(ExitStatus.FAILED);
というわけで、ChunkContext クラスから StepExecution を辿って、StepExecution#setStatus メソッドに BatchStatus.COMPLETED or BatchStatus.FAILED を渡すことで正常終了か異常終了を判別することができた。
ちなみに BatchStatus.FAILED を渡すと、ステータスコードに 5 が返る。
// 正常終了 chunkContext.getStepContext().getStepExecution().setStatus(BatchStatus.COMPLETED); // 異常終了 chunkContext.getStepContext().getStepExecution().setStatus(BatchStatus.FAILED);
ちなみに本家のクイックスタートにも記載されているが、ステータスコードを返すときは main メソッドで以下のようにして System#exit を呼び出す。
public static void main(String[] args) { System.exit(SpringApplication.exit(SpringApplication.run(FooBatchApplication.class, args))); }
src/main/resources に application.properties があって、プロジェクト直下に config/application-env.properties があるとする。このとき、両方のプロパティファイルを読み込むことを検証したい。
プロパティファイルの内容は次の通り。
app.foo=foofoo app.bar=barbar
env.hoge=hogehoge env.fuga=fugafuga
それぞれのプロパティファイルに対応する Bean を用意する。
@Component @ConfigurationProperties(prefix = "app") public class ApplicationProperties { private String foo; private String bar; // getter/setter は省略 }
@Component @ConfigurationProperties(prefix = "env") public class ApplicationEnvProperties { private String hoge; private String fuga; // getter/setter は省略 }
プロパティを使うときは、それぞれの Bean を DI して使う。
@Autowired private ApplicationProperties appProp; @Autowired private ApplicationEnvProperties envProp; ... appProp.getFoo()); // foofoo appProp.getBar()); // barbar envProp.getHoge()); // hogehoge envProp.getFuga()); // fugafuga
尚、application-env.properties を読み込むには、アプリケーションの実行時に -Dspring.config.location=config/application-env.properties を VM 引数に渡す必要がある。
VM 引数に -Dspring.config.location=config/application-env.properties を指定した場合、application-env.properties しか読み込まれないかと思っていたら、クラスパス上にある application.properties も普通に読み込まれていたので、特に深く考える必要はなかった模様...。
仕事で提案活動向けに画面のモックアップを作る機会がありまして、今回は Bootstrap ベースで作りました。
で、せっかくの機会なので Bootstrap の調査を兼ねて Bootstrap の機能をいくつか盛り込んだサンプルみたいなものを作りました。ログインから検索、参照、更新まで基本的な画面遷移をひと通り実装しています。
全体的に以下の日本語リファレンスを参考にしています。
また、以下を利用してサイドメニューを実装しています。(スタイルは若干変更)
アイコンはここ。
ご参考まで。
JSON を返すダミー API サーバを構築する際、以下が手軽で便利そうだったので使ってみる。
npm コマンドでインストール。
npm install -g json-server
API は JSON ファイルで作成する。次の場合、example が API のエンドポイントとなり、value のオブジェクトがレスポンスボディとなる。
{ "example": { "values": [ { "id": "1", "name": "foo" }, { "id": "2", "name": "bar" }, { "id": "3", "name": "baz" }, { "id": "4", "name": "hoge" }, { "id": "5", "name": "fuga" } ] } }
JSON Server を起動する。--watch オプションを付けると JSON ファイルの変更を監視してくれる。便利。
json-server --watch example.json
http://localhost:3000/example にアクセスすると以下のレスポンスが返る。
{ "values": [ { "id": "1", "name": "foo" }, { "id": "2", "name": "bar" }, { "id": "3", "name": "baz" }, { "id": "4", "name": "hoge" }, { "id": "5", "name": "fuga" } ] }
JSON Server 起動時に js ファイルを指定して、動的にレスポンスを生成することもできる。(未検証)
ルーティングについて。
JSON Server ではエンドポイントの設定に / を含めることができない。例えば、/example/10001 のような記述を db.json に書くことはできない。
そこで、次のような routes.json を用意する。
{ "/example/10001": "/example1", "/example/10002": "/example2" }
これに合わせて次のような db.json を用意。
{ "example1": { "values": [ // ... ] }, "example2": { "values": [ // ... ] } }
JSON Server 起動。
json-server --watch db.json --routes routes.json
http://localhost:3000/example/10001 にアクセスすると内部で /example1 にルーティングされて、db.json の example1 の内容が返却される。
