I want to avoid 'info' level logging for certain classes, while I want to allow all logs from other classes. How do i configure this scenario in my log4j2 xml file.
You would add loggers to your configuration with the names of the classes you don't want logged and specify a lever of error or fatal.
Related
The Citrus Framework documentation indicates that integration test console output can be logged via the SLF4J logging system. It's not obvious whether this is automatic, or whether it needs to be enabled in some way. My experience indicates that it's not enabled as no log file containing what appears on the test run console has been produced.
My application uses Log4J with an associated log4j2-spring.xml file (in src/main/resources) to define log formats and files. When an integration test is run via Citrus, the application console output (and other information) is properly logged to the files specified in the Log4J config file. There is however, no Citrus console output logged anywhere (except on the console).
How do I enable the logging of the Citrus test console output? I created a separate log4j.xml that I placed in src/test/resources, but this seems to have been ignored.
Do I need to specify a separate logger in the config that's specific for Citrus output?
Citrus uses SLF4J which is a facade to several other logging frameworks out there. So you need to pick your favorite logging framework (in your case Log4J) and add a SLF4J logger binding for that logging framework. This is all described in the SLF4J user manual
I would suggest to add the SLF4J logger binding for Log4J as a test scoped dependency in your project. Also depending on your Log4J configuration setup you may need to add a Log4J logger configuration for com.consol.citrus and set a proper logging level for that in order to see the Citrus output logged by Log4J.
I was playing a bit with Cygnus, and I was wondering how to properly configure it. I’ve seen both agent_<id>.conf and cygnus_instance_<id>.conf files are needed. I understand the purpose of the first one, but not the second one. In addition, what about the grouping_rules.conf file? Is there any other configuration file?
File by file:
agent_<id>.conf file is the main configuration file for Cygnus. It inherits the syntax from Apache Flume, the base technology used by Cygnus, thus it is used to declare and specify the sources, channels and sinks of your Cygnus agent.
cygnus_instance_<id>.conf file is used to configure other Cygnus parameters that cannot be configured as part of the agent configuration, such as the logging file, the management interface port, etc. Cygnus service will run as many instances as cygnus_instance_<id>.conf files are configured. That's why an <id> must be provided, since this <id> will be used to find the proper agent_<id>.conf file.
grouping_rules.conf file is used when the Grouping Rules advanced feature is wanted to be used. Usually, this file may be empty (but it must exist) and Cygnus will run after all.
flume-env.sh file has been inherited from Apache Flume, and it is used in order to configure certain Flume paramters such as the classpath overwritting the default one, some Java options (-Xms, -Xmx, etc)...
I'd like to write a custom CodeNarc rule that validates some aspects of Grails integration test classes. e.g. Spock integration tests should extend IntegrationSpec; not Specification.
But to do this, I need to filter on integration tests while visiting the classes in the rule, and I don't know how to do that.
One idea was to look at the source file path to see if it's in test/integration, but I don't know if it's possible to get the source path of a file.? Any other ideas?
You can definitely limit rule application based on path (as well as class name). Take a look at the configuring rules CodeNarc page.
In particular, you're probably looking for the applyToClassNames and doNotApplyToClassNames properties or the applyToFileNames and doNotApplyToFileNames properties, which should be available on any of the built-in Rules and any custom rules that extend the provided AbstractRule class.
Say I have a grails-master plugin that itself contains a (chained) "sub-plugin" called grails-widget. The master plugin pulls in the chained plugin like so:
// grails-master's BuildConfig.groovy:
plugins {
compile ':widget:1.0.5' // or whatever
}
This way, anytime a Grails app includes grails-master as a dependency, both master and chained plugins get pulled in.
Now let's say that the chained grails-widget plugin requires configuration. Let's say that if an app requires grails-widget directly (sans the master), then one must configure the plugin from inside the Grails app's Config.groovy like so:
grails.plugin.widget.fizz=1
grails.plugin.widget.buzz='YES'
... etc.
Here's what I'd like to accomplish, if at all possible:
If a Grails app just lists grails-master as a dependency, then the master pulls in grails-widget but provides default values for its fizz and buzz properties. This way, when the app declares grails-master, they do not need to define the above properties in its Config.groovy.
Again, if a Grails app just lists grails-master as a dependency, then although grails-master will (somehow, automagically) provide defaults for fizz and buzz, the app developer can still choose to define them in their app's Config.groovy. In this case, the app-defined values for fizz and buzz will override the defaults set back in grails-master.
Finally if the developer only lists grails-master as a dep, it would be nice to allow the app developer to disable the use of the (chained) grails-widget plugin altogether. Hence, anything the plugin does at app startup would not occur.
Are these items possible? If so, how could I accomplish them? If not, why?
Yes you can accomplish that. Default configs can be added when the master plugin is installed. Manually you can do as a post initialization configuration in doWithApplicationContext. But there is a convenient plugin-config plugin which can do that for you. Add this plugin to master plugin and set up default values for the widget plugin. The doc for plugin is self-explanatory. If not, I can add an example.
Any config provided by the plugin can be overridden in application's Config.groovy. Application's config is initialized in the end (after all plugins are initialized). So you can definitely override the default config which you would have setup from step 1 above.
You can exclude widget plugin from the master plugin when required, in application's BuildConfig.
Example:
//BuildConfig in application
plugins {
compile(':master:0.1') {
//exclusion based on some logic at build/compile time
if(some logic satisfied) {
excludes 'widget'
}
}
}
I'm building a plugin that will contain sharable code and configuration for several applications. One things that I'm trying to share is the data source information. Basically I need the application to not have to define it's own data source and instead use the plugin's data source. The best way that I can think of doing this is to take advantage of the external configuration functionality that's available in Grails (http://grails.org/doc/latest/guide/conf.html#3.4%20Externalized%20Configuration). However, I'm not exactly sure how to do this. All the examples I can find online show you how to do this when using an external file on the file system somewhere. I want to use configuration files from the plugin.
According to the documentation linked to above you can specify a "config script" class to use like this:
grails.config.locations = [com.my.app.MyConfig]
This would probably work, however, I can't find documentation on what a "config script" class actually is and how to create one.
By default, the DataSource file of your plugin will not be used (it's ignored in the package stage) but you can create another file that ends with "DataSource" (eg MyPluginDataSource). This is also true for BootStrap and Config.
You will probably need to leave the application DataSource file empty.