【Mybatis】Java共通ライブラリーとJavaアプリの両方でMybatisを使う - タイガー！タイガー！じれったいぞー！（SE編）

背景

前回に引き続き、オリジナルのJava共通ライブラリーとその共通ライブラリーを含んだ親Javaアプリで検証したときの話です。

今回の発端は、「RDBのシステム系マスタを参照する程度であれば、共通ライブラリーに入れてしまって楽をしよう！」ということでした。

そもそも共通ライブラリーはユーティリティ的な目的で使うことが多く、DBアクセス機能を実装すること自体が王道から外れてしまうのでは無いかと考えたのですが、各サブシステムが多すぎてカオス化してしまいそうだったので、実施に踏み切ることにしました。

実装

というわけで、元々のJavaアプリにあったコード（Javaクラス、Mybatis設定ファイルなど）を共通ライブラリーのプロジェクトへの複写しました。

まずは、共通ライブラリー側で動作確認です。

RDBへのアクセスも問題なし！

よし、よし！！　最高です。

次に、Javaアプリ側に戻り、Gradleの「build.gradle」ファイルに共通ライブラリーを加えます。（組織内のリポジトリー管理は、Sonatype Nexusになっています）

repositories {
    mavenCentral()
    maven {
        url "https://host.company.co.jp:8081/nexus/content/repositories/releases"
    }
}

dependencies {
    compile group: 'jp.co.company', name: 'java-commons', version: '1.4.0'
    // (省略)
    compile 'org.slf4j:slf4j-api:1.7.28'
    compile 'ch.qos.logback:logback-classic:1.2.3'
    testCompile group: 'junit', name: 'junit', version: '4.12'
}

Javaアプリ内でシステム系のテーブルを参照する部分のソースをjava共通ライブラリーのパスに変更していき、いざテストを行いました。

しかし・・・

例外が発生しました。。。

org.apache.ibatis.binding.BindingException: Type interface jp.co.company.commons.models.mappers.ServiceManagementMapper is not known to the MapperRegistry.

MapperRegistryが不明であるようです。

原因

しばらく頭を悩ませてしまいましたが、原因は下記の図を見れば一目瞭然です。

f:id:no14141:20200124164951j:plain

Mybatis用の設定ファイルを同じ名前にしてしまっていたことで発生しました。

これを別々の名前の設定ファイルにしたことで、問題なくアプリケーションは動作できました。

別名のConfigファイルでBuildした親JavaアプリをJar化して解凍してみると･･･

/ch
/Class50
/com
/jp
/lombok
/META-INF
commonsMessages.properties
commonsMybatis-config
LICENSE
logback.xml
messages.properties
mybatis-config.xml
:

共通ライブラリのリソースと、親Javaアプリのリソースは、ルートディレクトリ上に展開されていました。

基本中の基本の話なのかもしれませんね。

もしかすると、Gradle側の設定で、同じ名前のリソースでもうまく識別してくれるような機能があるのかもしれません（まだ未調査です）。

まずは、このスタイルで運用していこうと考えています。

まとめ

コピペは危険しかない。
原理原則を正しく理解しよう。