I want to send log messages to several files (i.e. different appenders) based upon some property of the message.
The problem is that each appender needs to specify quite a verbose layout (that contains a compication conversionPattern and a couple of converters). I have ended up duplicating this configuration in each appender. This works but is not ideal as it makes the config much longer than I would like as well as the pain of having to update 3 complicated bit of configuration when the layout changes.
I want to be able to define the layout once and have all my appenders refer back to that one definition (in the same way that several loggers can refer to the same appender). But perhaps there is a better way to achieve my goal of reducing duplication in the configuration?
My google-foo is weak and I could not find an answer. Can anyone here help?
TIA.
I am sorry but unless you are ready to code your own Layout class there is currently no way to skip on the copy-pasted configuration.
You can inherit from the LayoutSkeleton to get started, and either build your layout in code or use an alternate configuration file (I don't think that log4net would be kind to a dangling layout configuration in its config file)
Related
I have deployed a document library hook which includes many jsp files under custom_jsps.
Recently, I wanted to change folder_action.jsp, so I changed it and deployed it normally in document library portlet.
As it was expected, a folder_action.portal.jsp was created containing the original file.
However, I've noticed something strange. After stopping Tomcat both folder_action.jsp and folder_action.portal.jsp are deleted(this is not happening for the other files that come from the hook), and when it is up again a really strange thing happens. The folder_action.portal.jsp contains the changed file and the folder_action.jsp is the original file.
Has anyone met something similar ever? Any help would be appreciated.
You might run into a very nasty issue: You must only override a particular jsp from exactly one hook. If you override the same jsp from two different hooks, the scenario that you describe might happen (on undeploy). Worse: Order is not maintained, you might have some "wrong" files left over.
Find the two hooks that override the same jsp and determine which you like better (or merge the two). Find some more horror in this answer to a similar question
I am running Jira and Confluence within my company. I would like the logfiles to be shipped to Kibana.
This is very easy to do but I do not want to rewrite the Grok filters. I cannot imagine that nobody has done this already.
Does anybody have an example of a logstash shipper configuration. Most of the logging like catalina.log is standard.
Please help me with examples
One would think that Java application logs only come in one form, but my experience is that there often are subtle differences. Sometimes the thread name is in square brackets and sometimes in parentheses, sometimes the thread name goes first and other times after the logger name, and so on. This gets more painful as you attempt to parse more than one type of log.
Instead of messing with various filters to join multiline messages and grok all the fields I strongly favor using the Log4j layout in github.com/logstash/log4j-jsonevent-layout to produce JSON-based logs that Logstash can read directly without any filters. Apart from not having to maintain filters you get all fields from each log event. Since I don't know what your catalina.log looks like I can't say what you'd be missing by parsing its contents instead of using the JSON layout.
The drawback is that it's a bit more work deployment-wise. You obviously have to deploy the layout jar file itself, but it has a couple of dependencies of its own (net.minidev:jsonsmart and commons-lang:commons-lang) that you need to make available too.
I was asked to move from properties style configuration to xml style. The process itself is straightforward and it is not causing me any trouble, I was simply curious why I got asked this and I looked for the reason. I found this nice post Why chose XML over properties files for Log4J configuration? (more than 3 years old but still the most informative I could find), which was pointing pointing to this even older tutorial. They state
Properties can be defined by a properties file or by an XML file.
Log4j looks for a file named log4j.xml and then for a file named log4j.properties. Both must be placed in the src folder.
I checked it out and, contrary to the statement, found out that Log4j looks first for the properties file and in a second time for xml. In fact, if I keep both in the same folder, the output is formatted according to the properties file. So, am I misunderstood the statement? Is it simply wrong? The statement has been made for log4j 1.2.14 while I am on log4j 1.2.17, is it possible the log4j team changed the priority? I couldn't find any related documentation, but it will be a strange trend inversion since the xml looked to be the preferred way to configure log4j
Have a look at the JavaDoc. The documentation of the PropertyConfiguratorClass (log4j.properties) points out that
The PropertyConfigurator does not handle the advanced configuration
features supported by the DOMConfigurator such as support custom
ErrorHandlers, nested appenders such as the AsyncAppender, etc.
So the DOMConfigurator (log4j.xml) offers advanced options.
Beside that you can have (at least a simple) validity check of log4j.xml files using the provided log4j.dtd.
If youd do not make use of the advanced features it is needless to change from properties to xml files.
What you really should think about is to change from log4j to log4j 2 beta or even
slf4j. Development of log4j has stopped and the founder of it (#Ceki) invented slf4j.
As per FrVaBe's answer, the PropertyConfigurator class does not handle the advanced features that XML can support.
It's worth noting one of the more useful advanced options (only available log4j.xml) is the ability to filter on a specific log level or range of log levels using LevelMatchFilter and DenyAllFilter
A good example can be seen here.
I'm trying to find a better way to move my Expression Engine 2 sites from development to live servers. I have a checklist that I go through, starting with running a find and replace for the old/new URLs and server paths, then I update the database config file. This however misses out a huge amount of settings that I then have to go through and change manually, but I don't see why I should need to (unless these are encrypyed somewhere).
For example, I have to change the "Basepath to Template File Directory" in the Global Template Settings manually, along with member settings and a handful of others. There must be a file or entry with these in somewhere that I can change before I upload but I can't find it.
Does anyone know where these are stored?
Those are stored in the database, unless you are using global config variables.
I would highly recommend looking into some sort of config bootstrap. There are quite a few solutions to this, but it's really up to you to pick what's right for your development style / environment(s).
Take a look at the following articles:
http://eeinsider.com/articles/creating-a-robust-config.php-file/
http://boblet.tumblr.com/post/68095239/ee-localhost
http://eeinsider.com/articles/multi-server-setup-for-ee-2/
I've tried those solutions, but in my opinion the best option is NSM config bootstrap.
Check it out here: [http://ee-garage.com/nsm-config-bootstrap][4]
The only thing (currently) missing from these solutions are new config vars regarding file upload paths and locations. You can add those to any of these solutions by adding the variables detailed in this article:
http://expressionengine.com/user_guide/cp/content/files/file_upload_preferences.html#overriding-upload-paths-and-urls-using-configuration-variables
I know I'm late on this one, but for anyone else searching, this plugin is very useful and I have used it on numerous occasions.
ExpressionEngine stores your website URL and Server Path in a ridiculous number of places.
REElocate helps you update these in one simple step.
https://github.com/expressodev/reelocate
What is the best way to log to a file using log4net that has the correct format (correct XML, correct timestamp format, custom data in correct format, correct attributes, basically the exact same way as XmlWriterTraceListener does it) so it can be viewed in the Service Trace Viewer Tool (SvcTraceViewer.exe)?
If I wanted to this then I would write my custom layout. I did not (yet) look at the details but I would write a class that derives from XmlLayoutBase. I need some more time to look at the details...
You could also write your own appender but I think in this case it makes more sense to write a layout class.
Edit: Maybe writing your own appender is a good idea. In that case you could use the System.ServiceModel.Diagnostics.DiagnosticTrace class. Not sure yet though if that is the way to go. I do not have much time right now, but I will look into this.
Not an answer, but I asked a question earlier today about logging and WCF and one of the things I wanted to know was about Service Trace Viewer. All of the examples that I have seen describe the XML files consumed by Service Trace Viewer being generated via System.Diagnostics TraceSources and the System.Diagnostics XmlFileListener. Anyway, if I get any answers in my post you might find them useful.
Here is an idea:
You could write a custom log4net Appender and have it write messages (indirectly) to the XmlWriterTraceListener. Inside the Append method you simply send the message to System.Diagnostics.
Here is one example of a custom Appender.
In the example, Append is overridden. It is passed a LoggingEvent class/structure. For your purposes (to get the log4net output routed to an output format that can be read by SvcTraceViewer), you could write your output to System.Diagnostics (having first configured it to log to the XmlWriterTraceListener). You could either write using Trace.Write* methods, Trace.Trace* methods, or by TraceSources.
For TraceSources, you could consider the TraceSource name to be the same as the logger name (which is available in the LoggingEvent class/structure). So, you could configure a TraceSource in your app.config file for each log4net logger name that you want to go into the xml file. Your Append logic then might look something like this:
protected override void Append(LoggingEvent le)
{
TraceSource ts = new TraceSource(le.LoggerName); // Not sure of logger name field in LoggingEvent
ts.TraceEvent(LogLevelToTraceEventType(le.Level), 0, le.FormattedMessage);
}
This might give you what you want. Note that I have not actually done this, so I cannot say if it is a good idea or not, but it certainly seems like it would work.
Sorry for being brief, but am trying to finish this before have to leave.