mapper-locations logic is broken in container deployments if locations match existing package path #264
Description
MyBatisRecorder fails to resolve the mapper XML files if a location is also a package name. This hit me when doing my first container build, where Quarkus generates some synthetic classes in a separate jar - pls see example below.
This could be addressed in documentation, using locations that don't clash with package names resolves the issue.
-
Configuration:
quarkus.mybatis.mapper-locations=com/acme/core/mapping,... -
Where Quarkus should find the XML mapper file:
Thread.currentThread().getContextClassLoader().getResource("com/acme/core/mapping/account-mapper.xml")
jar:file:/deployments/lib/main/com.acme.ep-core-1.0-SNAPSHOT.jar!/com/acme/core/mapping/account-mapper.xml
- Where it goes instead with the logic in buildFromMapperLocations:
Thread.currentThread().getContextClassLoader().getResource("com/acme/core/mapping")
jar:file:/deployments/quarkus/generated-bytecode.jar!/com/acme/core/mapping