I am developing one automation testing framework for a web application testing. For this automation framework I want implement logging with log4j2.
In web I found that there is 4 different way to configure the log4j2 configuration
1) .xml
2) .yml
3) .properties
4) .json
I am confuse which configuration will be better for which purpose. Can anyone explain me for what kind of application/situation which configuration is suitable.
Also I want to know how I can implement log4j2 from start to end (any link)
You're completely free to use any! It's a matter of personal preference.
You can see that they have the same capabilities in the configuration documentation.
A properties file is definitely the simplest, but there's probably more documentation using XML. YAML is much richer, I would start with either properties or XML.
Related
I am trying to migrate from log4j1 to logj2.
I have a WLS server with two ear files. Ear1.ear and Ear2.ear. Both have similar code and for logging, they use the same logger name. In log4j1, there were two different config files loggingconfigEar1.xml and loggingconfigEar2.xml writing to ear1.log and ear2.log respectively.
I am trying to implement the same in log4j2, but not able to find an easy way out. Is it possible to have two different ears with same logger name have its own individual log files. Right now, I am initialising the config file through the System Property log4j.configurationFile and it does not work.
The only other option that I can think of is, have separate logger names for the two ears. But that would involve code change in quite a few places and I want to have it as a last resort option.
FYI, there was a lot of customisation done for log4j1 which I have avoided in the migration either by scrapping the functionality or by rewriting code. I am not sure how exactly this separate logging was achieved in log4j1.
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
There is a mention in the docs of using the logging package to create a proper logger service. Given the features in the logging package it would be nice to be able to get the angular component tree as the logger full name.
I tried to play a bit with the dependency injection system to get the injector tree, so that I could reconstruct the app structure for the loggers. But this proved to be too tricky.
Is there a way to do this, or alternatively, is there a canonical logger service that I could use? It seems to be a pretty basic feature so it must be available somewhere.
I'd look at the logging package for help here.
This is not Angular-specific, but it supports tested loggers.
I'm developing a plugin for Redmine and encountered an issue of how to implement plugin specific settings in Redmine in the most neat way.
Is it possible to have a plugin specific settings in {redmine_home}/plugin/{my_plugin}/config/settings.yml while sharing with a core a model (in MVC terms) logic which reads YAML file, sets attributes of the model class, provides easy access to them, etc. ({redmine_home}/app/models/setting.rb)
I think copypasting or require'ing the core model in the plugin model is definitely a poor design so right now i'm tending to have a plugin specific settings in the core config {redmine_home}/config/settings.yml and when it comes to plugin controller to read a settings it relies on the core model to do that. ({redmine_home}/app/models/setting.rb)
Is this a proper design? Is there any better ways to do this?
Thanks.
I just checked 3 different plugins in our project all used something like:
options = YAML::load( File.open(File.join(Rails.root, 'plugins/fancy_plugin/config', 'settings.yml')))
So just copy pasting.
I'm investigating Grails vs. other Agile web frameworks, and one key use case I'm trying to support is the ability to modify controllers and install plugins post deployment. It appears that this isn't possible with Grails, but I want to make sure before I write it off.
As far as modifying controllers goes, it would be sufficient if the Groovlet behavior existed (compile-on-demand).
As far as plugin installs go, I understand this may be a long shot, but I thought I'd check to be sure.
For your information, I need this because I work on a product that requires a little site-specific customization, such as adding validation of simple meta-data, integrating with customer security environments, and maybe even including new controllers/pages quickly.
Out of the box, no, grails doesn't really support what you want. There may be ways to customize it but I've never looked into it. A PHP framework might be more of your ally since there is no real deployment process other than copying PHP files to a location.
That said, I personally would prefer a strict set of deployment policies. And honestly, deploying changes with Grails is as simple as running the 'grails war' command and copying that war to your servlet container. The site's downtime is negligible and if you have multiple web servers with a load-balancer, your customers should never see down time due to deployments.
Although it's not recommended for complex coding; You could execute groovy code from a string that you could store in database or a file on the fly at run time:
check out Groovy template engine:
http://groovy.codehaus.org/Groovy+Templates
but even then, you are still limited on what you can do or can't do let alone debugging will lack. you may want to consider an interpreted language; few to mention PHP/Perl/Coldfusion.