new logback situation hasn't been thought through

[xpusostomos]

Feature description

Back in the good old days, when we had logback.groovy, the standard logback.groovy that create-app gave you, had some conditionals based on being in development mode.

The new logback.xml in grails 5.1 doesn't. Is this because the grails team had a change of heart about what the default logging should be? Probably not.

So it raises the question, how do you do conditional login setup based on grails 5?

According to the logback documentation, it encourages you to have a logback-test.xml which it says you should put in src/test/resources . This doesn't work, as far as I can see, it isn't picked up when you run grails as a development run. So that option seems ruled out, and besides which, it doesn't seem to follow the grails philosophy to have a test setup that isn't in the war, and isn't based on the development/test/production trilogy.

So the other other option alluded to in the logback documentation is to use janino:

implementation "org.codehaus.janino:janino:3.1.6"

However this isn't included in the standard grails setup.

Then you can put this in logback.xml:

    <if condition='property("grails.env").equals("development")'>
        <then>
                blah
       </then
    </if>

Since supposedly logback.groovy is too dangerous (How? If you have access to the server, then you're screwed anyway)... but when I look at what Janino is... it appears to be some kind of a Java interpreter. Does swapping one pseudo java/groovy interpreter for another java interpreter save you from anything? I don't know.

Anyway, it seems to me that grails needs to give users guidance on the official way to do environment based log setup in this new world. If it's Janino, then I think it should be in standard grails... or at least documented.

[lifeweaver]

I miss Logback configuration via Groovy too, but I switched over to configuring in a Groovy class, and it's not too bad. It's certainly better than XML in my opinion.

[xpusostomos]

@lifeweaver What do you mean by configuring in a groovy class?

[lifeweaver]

https://logback.qos.ch/manual/configuration.html, see # 3 about the 'service-provider loading facility'. Then you can just configure your logging via a class implementing the logback Configurator class. Note this link was useful(Part about ContextAwareBase): https://stackoverflow.com/a/65117149/2137125. I would have preferred to implement ApplicationContextInitializer, but I couldn't figure out how to make it work with Grails.

[xpusostomos]

@lifeweaver The thing is... you kinda want to be able to configure logging at runtime, after it's deployed if necessary. Now one could load one of these classes dynamically I suppose, but then you have a poor man's logback.groovy.

I still don't get the rationale for removing logback.groovy. Maybe there are some scenarios, like a desktop app, where it would be dangerous, but on a server app, you control the server's files, you control the server period. I think grails should take over the logback.groovy interface for use in grails. Let people decide if this option is right for them.

[lifeweaver]

I understand runtime log configuration is a feature many use, in my situation I couldn't wait. As for the rationale, the Logback team made the decision, I don't like it and agree with your thoughts. If you feel strongly about it, I suggest checking out: https://jira.qos.ch/browse/LOGBACK-1606, someone has already suggested putting it as a separate module.

[davidkron]

As Grails effectively is a Spring Boot application, there is this option, without adding additional dependencies: https://docs.spring.io/spring-boot/docs/2.6.x/reference/htmlsingle/#features.logging.logback-extensions.profile-specific

I can't remember why, but for this to work you have to name the file logback-spring.xml.

[xpusostomos]

In my opinion, Grails should refrain from using this new logback, until the groovy configuration is fixed, whether by a new logback module or whatever. There's no benefit here for the grails community, even if it benefits some other usage scenarios. To my mind, logback have [made a mistake with] their product.

[jeffscottbrown]

@xpusostomos Thank you for all of the feedback. It really is appreciated. I edited your previous comment to use more inclusive language without changing the intent of the message.

Thank you again.

[jeffscottbrown]

So it raises the question, how do you do conditional login setup based on grails 5?

There are a few options. One is described at https://github.com/grails/grails-core/releases/tag/v5.1.2 which includes setting logback.version=1.2.7.

[humberthardy]

Another option can be use a different XML via configuration.
Let's say:

• logback-development.xml -> ConsoleAppender
• logback.xml -> FileAppender

You just have to set the logging.config property in application.yaml:

environments:
  development:
    logging:
      config: "grails-app/conf/logback-development.xml"

[jeffscottbrown]

Since supposedly logback.groovy is too dangerous

I don't consider logback.groovy to be particularly dangerous. The kinds of problems one could create there could be created lots of places.

[Trebla7th]

I don't consider logback.groovy to be particularly dangerous. The kinds of problems one could create there could be created lots of places.

It seems that most of the community (myself included) agrees with this and disagrees with the decision to remove groovy configuration support. The reason provided by Logback in the release notes (version 1.2.9 - https://logback.qos.ch/news.html) is:

Removed Groovy configuration support. As logging is so pervasive and configuration with Groovy is probably too powerful, this feature is unlikely to be reinstated for security reasons.

and this change "...is intended to prevent an escalation of an existing flaw to a higher threat level."