For what it is worth, I had no idea that's what was being done
automatically. I'd say grails-logging promotes convention over
configuration.
Looking over the source code for grails-logging, it seems like it would not
be too difficult to maintain given how few lines of code there are.
https://githu
A small but related issue:
https://github.com/grails/grails-core/issues/10969
Jeff
Jeff Brown
Partner, Distinguished Engineer
mobile (314) 368-7771
objectcomputing.com
TECHNOLOGY THAT EMPOWERS™
On Wed, Mar 12, 2025 at 12:06 PM Mattias Reichel
wrote:
> In my Grails applications, I remove t
My view is one of Grails core raison detre is to assert Convention over
Configuration and this moves that agenda forward.
On Wed, Mar 12, 2025 at 1:08 PM Mattias Reichel
wrote:
> In my Grails applications, I remove the grails-logging library and
> explicitly annotate classes with @Slf4j where lo
We are also explicitly adding @Slf4j where we need logs so we can have auto
completion with IntelliJ Community Edition.
Another plus is that the “log” usage is documented by the annotation.
I have this idea we should define the “conventions” to help Grails be
perceived less “of the elite” and mor
In my Grails applications, I remove the grails-logging library and
explicitly annotate classes with @Slf4j where logging is needed.
My question is: Is it worth maintaining a library whose sole purpose, as
far as I know, is to automatically add @Slf4j to all Grails artifact
classes?
Thanks for your input!
I fully embrace the Convention over Configuration philosophy as the
backbone of Grails.
However, for grails-logging, I'm not sure if it's helping or hurting.
Thanks to Groovy, we already have clean and powerful log object
configuration/injection out of the box.
For Slf4j an
