From time to time we like everyone else like to use plugins. Unfortunately they are not always documented all that well. Sometimes you get lucky and find OH DEBUGGING LOG's have been included.
How do you turn on logging for the plugins?
If the plugin is packaged org.plugin.special and the following is our logging setup, how do we add it?
log4j = {
appenders{
rollingFile name: "myAppender", maxFileSize: 1024, file:'/development/log/eightstates.log'
console name:'stdout', layout:pattern(conversionPattern: '%c{2} %m%n'), threshold: org.apache.log4j.Level.DEBUG
}
debug myAppender: [
'grails.app.controllers.come.example.eightstates',
'grails.app.domain.come.example.eightstates',
'grails.app.services.come.example.eightstates',
'grails.app.taglib.come.example.eightstates',
'grails.app.conf.come.example.eightstates',
'grails.app.filters.come.example.eightstates',
'grails.app.controllers.org.grails.paypal']
}
I think the reason there's not a single logger for plugins is because it's dependent on the artefacts used in the plugin. For example if the plugin uses a controller, then the logger for that will be different than the one used in the plugin's service, and so forth. Unless the plugin offers its own hooks to enable/disable logging, I think your best bet is to enable each artefact individually (which may take a while). I'm not 100% sure, but that's the experience I've had.
This thread talks about logging for the Resources plugin, if that helps at all.
Related
I've been tasked to setup a logging system that uses Apache Pulsar as the appender to Log4j2. I'm really lost on how to set this up and there doesn't seem to be any documentation/examples to go by. Does anyone have an idea how to go about this?
I found an example in the Pular Appender's test project. I would suggest you look at that as it shows 5 different configurations. However, I would not recommend the SerializedLayout as it can lead to security vulnerabilities.
Is there any way to customize logging on Neo4j 3+? Something like logback.xml where I can define log pattern, output files, levels, rolling policy and so on.
If you're talking about using Neo4j Server, then the logging configuration is available in the neo4j.conf file, with options prefixed by dbms.logs.: https://neo4j.com/docs/operations-manual/current/reference/configuration-settings/
These options include log level, output files, rotation policy, etc.
If you're using Neo4j embedded in another application (which you probably shouldn't), then you can use the setUserLogProvider(...) of the GraphDatabaseFactory. If you want to route user logging to another framework, there is a Slf4jLogProvider in the neo4j-logging jar, which can be used to send logs to slf4j and onto wherever you like.
As we know by default logging in Grails 3.0 is handled by the Logback logging framework and can be configured with the grails-app/conf/logback.groovy file. The good part of this was that the configuration inside this file was applicable for the Logback and Log4j implementations (tested successfully in Grails 3.1.2). After we migrated to use Grails 3.2.8 from Grails 3.1.2 (as I said before), it seems that the configuration inside the logback.groovy file is not used by the Log4j and it should be configured in other way - at runtime.
I made a deep research in this to ensure that this is really the way it is configured now and it seems that if I am using the default Log4j logging:
org.apache.log4j.Logger.getLogger("name").info("TEST");
is not working at all. To make the information populated into the output log file, I should use the default SLF4J API:
org.slf4j.LoggerFactory.getLogger("name").info("TEST");
The problem here is because that we have a lot of places in the code where the logging is implemented using Log4j approach and now - nothing is written in the log file.
So I have two questions here. The first one - is this the exact way how Grails implemented this behavior (as nothing is mentioned in the official documentation - Grails 3.2.8 Documentation). The second one - is the XML or RUNTIME configurations are the best way to configure the Log4j, so use it as before. If yes - the bad thing here is that we should maintain two same configurations at a time. Is there any other way to configure the Log4j to use the same configuration as the Grails Logger.
P.S. There is no need to publish any code, as all are just default configurations.
Thanks a lot!
appender('STDOUT', ConsoleAppender) {
encoder(PatternLayoutEncoder) {
charset = Charset.forName('UTF-8')
}
}
root(ERROR, ['STDOUT'])
logger("<package_name>", DEBUG)
List artifacts = ["conf", "controllers", "domain", "init"]
artifacts.each { artifact ->
logger("grails.app.${artifact}.<package_name>", DEBUG)
}
After writing this, you can add logger for debugging in any artifacts mentioned above like:
log.debug "Any Message"
For more setting you can read here: https://logback.qos.ch/manual/groovy.html
I am using STS and sometimes when I stop my app on a crash it opens up to a hundred different class files that seem to be deep deep inner working stuff. HTTPBuilder just stopped working, and I suspect its because I accidentally typed in one of these files and absent mindedly saved it. If I somehow destroyed a local file involved in HTTPBuilder, how would I refresh my dependencies? (have done install-plugin rest and also uncommented everything in BuildConfig.groovy repositories)
My specific problem and error is here:
Grails: HTTPBuilder stopped working suddenly
UPDATE: As much as I would love to blame STS, as you can see from my answer to my own other question, I was purely thwarted by my own carelessness.
We had an issue today that we suspect was due to the Artifactory Migration. Your problem may be similar. The first thing we did to diagnose the issue was to turn up the debug logging in BuildConfig.groovy (change log "warn" to log "debug"). Once we did that, it was evident that the Grails repos in Artifactory appear to be responding differently to queries made to calculate dependencies. To workaround these issues, we:
Removed grailsCentral, grailsHome, and grailsPlugins from BuildConfig
Added grailsRepo "http://grails.org/plugins" to BuildConfig
Changed one of our dependencies so that its transitive dependencies used specific versions instead of version ranges.
For 3, our specific example was to change:
runtime 'com.amazonaws:aws-java-sdk:1.3.4'
to
runtime 'com.amazonaws:aws-java-sdk:1.3.4', {
excludes "commons-logging",
"httpclient", "jackson-core-asl", "jackson-mapper-asl"
}
runtime 'org.codehaus.jackson:jackson-core-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
runtime 'org.codehaus.jackson:jackson-mapper-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
I'm not sure whether all of these steps were necessary, but they allowed us to move forward.
I am trying to figure out how to disable javamelody grails plugin completely. Following http://www.grails.org/plugin/grails-melody, I set javamelody.disabled = true in GrailsMelodyConfig.groovy. For some reason, this disables monitoring in a sense that I cannot navigate to myapp/monitoring to view info. More debugging showed that even if I disabled it, it is still calling doWithDyanmicMethod which adds invokeMethod on each services.
Is there something else I am missing? If it adds invokeMethod on each services, this defeats the point of disable.
According to the documentation:
The parameter disabled (false by default) just disables the
monitoring. This allows for example to disable the monitoring
temporarily or only on some servers, from the tomcat context or from
system properties without modifying the web.xml file neither the war
file of the monitored webapp.
But maybe you can disable the whole monitoring by using the 'url-exclude-pattern' option. Hope this helps.
This could be disabled all meta programming by adding context-param javamelody.disabled in web.xml. So to avoid calling doWithDyanmicMethod part.