propertySources attribute behavior in @MicronautTest is confusing

[asarkar]

trafficstars

Task List

• [ ] Steps to reproduce provided
• [x] Stacktrace (if present) provided
• [ ] Example that reproduces the problem uploaded to Github
• [x] Full description of the issue provided (see below)

Actual Behaviour

Given the project structure above, and @MicronautTest(propertySources = ["persistence.yml"]), ProjectRepositoryTest fails with the following exception:

No bean of type [io.micronaut.data.operations.PrimaryRepositoryOperations] exists in the test

Upon chatting on Gitter with @jameskleeh, turned out this is due to the fact that the file persistence.yml is searched for relative to the test class in the same package. No warning is logged when it's not found.

Tell us what should happen

propertySources should always be prefixed with either classpath or file. If a path starts with /, it's considered to be from the root of the classpath or file system, otherwise relative to the test class.

Better yet, deprecate propertySources in favor of https://github.com/micronaut-projects/micronaut-core/issues/5176.

[jeffscottbrown]

propertySources should always be prefixed with either classpath or file. If a path starts with /, it's considered to be from the root of the classpath or file system, otherwise relative to the test class.

If the value has to be prefixed with classpath or file I think that would be a breaking change and would remove the possibility for folks to use a relative path.

[jeffscottbrown]

Sorry... I understand now. It would be a breaking change, but it wouldn't prevent folks from using a relative path.

[jameskleeh]

I don't think this behavior should be removed or changed, however the documentation should instead show as an example the more common use case of classpath:x. I see the relative classpath feature as something pretty niche that most users would not be interested in.

Also we should throw an error, or at least a warning when the file is not found

[asarkar]

@jameskleeh My suggestion is intended to make the behavior consistent and intuitive. May be some people don’t need relative classpath, but that’s what is happening today without the prefix. Wouldn’t it be nice if both prefixes work the same way?

[jameskleeh]

Wouldn’t it be nice if both prefixes work the same way?

I'm not sure what you mean here. There are 2 prefixes, file and classpath and they are consistent in that there is no relative path. They both expect the full path either at the start of the file system or the start of the classpath.

If a path starts with /, it's considered to be from the root of the classpath or file system, otherwise relative to the test class.

Having classpath:foo.yml changed to be relative to the test class instead of absolute would be less intuitive compared to its current behavior imo

[asarkar]

classpath:foo.yml changed to be relative to the test class instead of absolute would be less intuitive

This currently is absolute compared to foo.yml which is relative, hence the confusion. Making classpath:foo.yml relative would make it exactly the same behavior as you'd expect file:foo.yml to work. Anyway, I'll leave it here.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.