Logback config not properly referenced for a self-containing JAR

[MarcelHB]

Hello,

When I started to run my Jooby application as a standalone, fat JAR, I noticed that any logging configuration seems to be lost completely. I have something boring as this in the docs:

conf/
  application.conf
  application.prod.conf
  logback.prod.xml
  logback.dev.xml

All files are included in the JAR file and configured as classpath. Anyway, no luck. So I debugged the loading into the respective section of LogConfigurer: https://github.com/jooby-project/jooby/blob/17e2c1b1ad9052f21e62decf72afe9e68dfad4b4/jooby/src/main/java/io/jooby/LogConfigurer.java#L63-L65

We see that the files are expected inside of a user.dir location. This is somewhat conflicting to my idea of a self-containing JAR package. I wrote this kind of workaround before initializing the Logger in the Jooby body:

System.setProperty("logback.configurationFile", String.format("logback.%s.xml", getEnvironment().getActiveNames().get(0)));

That's OK for now but I'm wondering whether I've missed something, or if it's worth noting in the docs?

Regards

[agentgt]

It is somewhat documented: https://jooby.io/#configuration-default-environment Could be better.

And it is definitely documented in the Javadoc.

The reason is probably to allow changing the configuration on the fly as both logback and log4j2 have that ability if it's an actual file and not a classpath resource (well there is some ability in servlet containers but lets ignore that).

It probably should fallback to classpath.

[MarcelHB]

It is somewhat documented: https://jooby.io/#configuration-default-environment Could be better.

This only mentions application.conf explicitly, and this works as expected by case 3 I guess. That's what made me question why we cannot simply have this for these log configs as well.

[agentgt]

Oh should probably emphasize more that I agree with you.

Let me inject a mostly postive rant:

If anything I think Jooby should not be in the business of trying to guess logging config like "spring-boot" particularly if it is going to do it its own way.

In fact I have mentioned this once or twice to @jknack how I hope 3.0 just focuses on being the best HTTP REST/MVC library and not "Spring Boot lite". At least 2.0 does not have or depend on an injection framework.

Providing all this support for modules (regardless of how thin they are) as well as even custom logging config brings along technical debt and distraction. Many of the issues are about random modules or extensions.

However I realize there are great merits for the modules/extensions as well as an opinionated convention over configuration particularly for attracting new developers (e.g improving network effect).