To my best knowledge, RollingFileAppender in log4j2 will not roll over at the specified time (let's say - at the end of an hour), but at the first log event that arrives after the time threshold has been exceeded.
Is there a way to trigger an event, that on one hand will cause the file to roll over, and on another - will not append to the log (or will append something trivial, like an empty string)?
No there isn't any (built-in) way to do this. There are no background threads monitoring rollover time.
You could create a log4j2 plugin that implements org.apache.logging.log4j.core.appender.rolling.TriggeringPolicy (See the built-in TimeBasedTriggeringPolicy and SizeBasedTriggeringPolicy classes for sample code.)
If you configure your custom triggering policy, log4j2 will check for every log event whether it should trigger a rollover (so take care when implementing the isTriggeringEvent method to avoid impacting performance). Note that for your custom plugin to be picked up, you need to specify the package of your class in the packages attribute of the Configuration element of your log4j2.xml file.
Finally, if this works well for you and you think your solution may be useful to others too, consider contributing your custom triggering policy back to the log4j2 code base.
Following Remko's idea, I wrote the following code, and it's working.
package com.stony;
import org.apache.logging.log4j.core.LogEvent;
import org.apache.logging.log4j.core.appender.rolling.*;
import org.apache.logging.log4j.core.config.plugins.Plugin;
import org.apache.logging.log4j.core.config.plugins.PluginFactory;
#Plugin(name = "ForceTriggerPolicy", category = "Core")
public class ForceTriggerPolicy implements TriggeringPolicy {
private static boolean isRolling;
#Override
public void initialize(RollingFileManager arg0) {
setRolling(false);
}
#Override
public boolean isTriggeringEvent(LogEvent arg0) {
return isRolling();
}
public static boolean isRolling() {
return isRolling;
}
public static void setRolling(boolean _isRolling) {
isRolling = _isRolling;
}
#PluginFactory
public static ForceTriggerPolicy createPolicy(){
return new ForceTriggerPolicy();
}
}
If you have access to the Object RollingFileAppender you could do something like:
rollingFileAppender.getManager().rollover();
Here you can see the manager class:
https://github.com/apache/logging-log4j2/blob/d368e294d631e79119caa985656d0ec571bd24f5/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/rolling/RollingFileManager.java
Related
I need to build a custom command in a Grails 4 application (https://docs.grails.org/4.0.11/guide/single.html#creatingCustomCommands), and I need to get an handle to some Grails Services and Domain classes which I will query as needed.
The custom command skeleton is quite simple:
import grails.dev.commands.*
import org.apache.maven.artifact.Artifact
class HelloWorldCommand implements GrailsApplicationCommand {
boolean handle() {
return true
}
}
While the documentation says that a custom command has access to the whole application context, I haven't found any examples on how to get an handle of that and start accessing the various application artifacts.
Any hints?
EDIT: to add context and clarify the goal of the custom command in order for further recommendation/best practices/etc.: the command reads data from a file in a custom format, persist the data, and writes reports in another custom format.
Will eventually be replaced by a recurrent job, once the data will be available on demand from a third party REST API.
See the project at github.com/jeffbrown/marco-vittorini-orgeas-artifacts-cli.
grails-app/services/marco/vittorini/orgeas/artifacts/cli/GreetingService.groovy
package marco.vittorini.orgeas.artifacts.cli
class GreetingService {
String greeting = 'Hello World'
}
grails-app/commands/marco/vittorini/orgeas/artifacts/cli/HelloCommand.groovy
package marco.vittorini.orgeas.artifacts.cli
import grails.dev.commands.*
class HelloCommand implements GrailsApplicationCommand {
GreetingService greetingService
boolean handle() {
println greetingService.greeting
return true
}
}
EDIT:
I have added a commit at github.com/jeffbrown/marco-vittorini-orgeas-artifacts-cli/commit/49a846e3902073f8ea0539fcde550f6d002b9d89 which demonstrates accessing a domain class, which was part of the question I overlooked when writing the initial answer.
I would like to add to my log a String key and an Integer value using Log4j2.
Is there a way to do it? when I added properties to the ThreadContext I was able to add only String:String key and values but this does not help I have numbers that I need to present in Kibana (some graphs)
thanks,
Kobi
The built-in GelfLayout may be useful.
It's true that the default ThreadContext only supports String:String key-values. The work done in LOG4J2-1648 allows you to use other types in ThreadContext:
Tell Log4j to use a ThreadContext map implementation that implements the ObjectThreadContextMap interface. The simplest way to accomplish this is by setting system property log4j2.garbagefree.threadContextMap to true.
The standard ThreadContext facade only has methods for Strings, so you need to create your own facade. The below should work:
public class ObjectThreadContext {
public static boolean isSupported() {
return ThreadContext.getThreadContextMap() instanceof ObjectThreadContextMap;
}
public static Object getValue(String key) {
return getObjectMap().getValue(key);
}
public static void putValue(String key, Object value) {
getObjectMap().putValue(key, value);
}
private static ObjectThreadContextMap getObjectMap() {
if (!isSupported()) { throw new UnsupportedOperationException(); }
return (ObjectThreadContextMap) ThreadContext.getThreadContextMap();
}
}
It is possible to avoid ThreadContext altogether by injecting key-value pairs from another source into the LogEvent. This is (briefly) mentioned under Custom Context Data Injectors (http://logging.apache.org/log4j/2.x/manual/extending.html#Custom_ContextDataInjector).
I found default log4j2 implementation somewhat problematic for passing custom fields with values. In my opinion current java logging frameworks are not well suited for writing structured log events
If you like hacks, you can check https://github.com/skorhone/gelfj-alt/tree/master/src/main/java/org/graylog2/log4j2 . It's a library written for gelf. One of provided features is a layout (ExtGelfjLayout) that supports extracting custom fields (See FieldExtractor) from events. But... im order to send such event, you need to write your own logging facade on top of log4j2.
I've made a SAX parser for parsing XML files with a number of different tags. For performance reasons, I chose SAX over DOM. And I'm glad I did because it works fast and good. The only issue I currently have is that the main class (which extends DefaultHandler) is a bit large and not very easy on the eyes. It contains a huge if/elseif block where I check the tag name, with some nested if's for reading specific attributes. This block is located in the StartElement method.
Is there any nice clean way to split this up? I would like to have a main class which reads the files, and then a Handler for every tag. In this Tag Handler, I'd like to read the attributes for that tag, do something with them, and then go back to the main handler to read the next tag which again gets redirected to the appropriate handler.
My main handler also has a few global Collection variables, which gather information regarding all the documents I parse with it. Ideally, I would be able to add something to those collections from the Tag Handlers.
A code example would be very helpful, if possible. I read something on this site about a Handler Stack, but without code example I was not able to reproduce it.
Thanks in advance :)
I suggest setting up a chain of SAX filters. A SAX filter is just like any other SAX Handler, except that it has another SAX handler to pass events into when it's done. They're frequently used to perform a sequence of transformations to an XML stream, but they can also be used to factor things the way you want.
You don't mention the language you're using, but you mention DefaultHandler so I'll assume Java. The first thing to do is to code up your filters. In Java, you do this by implementing XMLFilter (or, more simply, by subclassing XMLFilterImpl)
import java.util.Collection;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;
import org.xml.sax.helpers.XMLFilterImpl;
public class TagOneFilter extends XMLFilterImpl {
private Collection<Object> collectionOfStuff;
public TagOneFilter(Collection<Object> collectionOfStuff) {
this.collectionOfStuff = collectionOfStuff;
}
#Override
public void startElement(String uri, String localName, String qName,
Attributes atts) throws SAXException {
if ("tagOne".equals(qName)) {
// Interrogate the parameters and update collectionOfStuff
}
// Pass the event to downstream filters.
if (getContentHandler() != null)
getContentHandler().startElement(uri, localName, qName, atts);
}
}
Next, your main class, which instantiates all of the filters and chains them together.
import java.util.ArrayList;
import java.util.Collection;
import org.xml.sax.XMLReader;
import org.xml.sax.helpers.XMLReaderFactory;
public class Driver {
public static void main(String[] args) throws Exception {
Collection<Object> collectionOfStuff = new ArrayList<Object>();
XMLReader parser = XMLReaderFactory.createXMLReader();
TagOneFilter tagOneFilter = new TagOneFilter(collectionOfStuff);
tagOneFilter.setParent(parser);
TagTwoFilter tagTwoFilter = new TagTwoFilter(collectionOfStuff);
tagTwoFilter.setParent(tagOneFilter);
// Call parse() on the tail of the filter chain. This will finish
// tying the filters together before executing the parse at the
// XMLReader at the beginning.
tagTwoFilter.parse(args[0]);
// Now do something interesting with your collectionOfStuff.
}
}
What is the preferred way to remove a default pipeline contributor (OpenRasta 2.0.3)?
I haven't found a lot on that on the net, but one way seems to be writing a custom DependencyRegistrar, i.e. deriving from DefaultDependencyRegistrar and then e.g. overriding AddDefaultContributors(). Apart from that I doubt that it's the best way to remove just a single pipeline contributor, it seems to need additional per-host (ASP vs. InMemory) work, whereas I would consider messing with pipeline handlers to be a host-agnostic affair.
But even if I'd go this route, this guy here seems to have tried it without success: http://groups.google.com/group/openrasta/browse_thread/thread/d72b91e5994f402b
I tried similar things, but so far couldn't make my custom registrar replace the default.
So what's the simplest and best way to remove a default pipeline contributor, preferable in a host agnostic way? Is there a working example somewhere?
No, you just need to derive from the registrar and use the protected members that are available to imperatively remove the types you don't want auto-registered.
The registrar needs to be registered in your container before you provide it to OpenRasta, otherwise the type has been resolved already.
Answering myself with working code snippets as they might be helpful to others.
So it looks like removing default pipeline contributors cannot be done
in a host agnostic way (although I don't see why OpenRasta could not
be modified to allow for easy deletion of handlers in the future).
The 2 classes that need to be written are in fact independent of the
host(s) used:
public class MyDependencyRegistrar : DefaultDependencyRegistrar
{
protected override void AddDefaultContributors()
{
base.AddDefaultContributors();
PipelineContributorTypes.Remove(typeof(HandlerResolverContributor));
// If we remove the only contributor for the 'well-known'
// IHandlerSelection stage, like done above, we need to add
// another one implements IHandlerSelection, otherwise
// we'll run into errors (and what's the point of a pipeline
// without a handler selector anyway?). So let's do that here:
AddPipelineContributor<MyOwnHandlerResolverContributor>();
}
}
In order to make that Registrar available, we need to create an accessor
like the following, which then needs to be set in the various hosts:
public class MyDependencyResolverAccessor : IDependencyResolverAccessor
{
InternalDependencyResolver resolver;
public IDependencyResolver Resolver
{
get
{
if (resolver == null)
{
resolver = new InternalDependencyResolver();
resolver.AddDependency<IDependencyRegistrar, MyDependencyRegistrar>();
}
return resolver;
}
}
}
For Asp.Net, this seems to work for me:
public class Global : System.Web.HttpApplication
{
void Application_Start(object sender, EventArgs e)
{
OpenRastaModule.Host.DependencyResolverAccessor =
new MyDependencyResolverAccessor();
For InMemoryHost, which I use for integration testing and in-process access
of my handlers, I haven't found a way around copying the whole class
InMemoryHost and modifying it to my needs. In fact, we don't need
MyDependencyResolverAccessor in this case, as InMemoryHost implements
IDependencyResolverAccessor already. So here's how it could look like. Only the
last line was actually added to the existing code in InMemoryHost:
public class TwinMemoryHost : IHost, IDependencyResolverAccessor, IDisposable
{
readonly IConfigurationSource _configuration;
bool _isDisposed;
public TwinMemoryHost(IConfigurationSource configuration)
{
_configuration = configuration;
Resolver = new InternalDependencyResolver();
Resolver.AddDependency<IDependencyRegistrar, MyDependencyRegistrar>();
...
Ok, so I'm looking at NLog. Based on the usage, my application would be tied to the logging framework. How do I overcome this?
Also, when using NLog, I have to write too much monkey-code for every class I'm using this framework on. Is it a good practice to make one static class and access it from anywhere in my application?
example:
//the monkey code
private static Logger logger = LogManager.GetCurrentClassLogger();
//the coupling.
logger.Log(/*...*/);
Create your own logging interface:
public interface IMyOwnLogger {
void Log(string message);
}
Create implementation:
public class NLogLogger : IMyOwnLogger {
void Log(string message) {
StackFrame frame = new StackFrame(1, false);
Logger logger = LogManager.GetLogger(frame.GetMethod().DeclaringType.FullName);
logger.Log(/*...*/);
}
}
Bind IMyOwnLogger to NLogLogger in your IOC container.
Inject where needed (or use IOC.Get<IMyOwnLogger>()).
EDIT:
Idsa made a comment about loosing calling class. Remember you can always use stack trace:
var method = (new StackTrace()).GetFrame(1).GetMethod()
and extract calling class from there.
EDIT:
This is how GetCurrentClassLogger in NLog looks like, so using StackTrace in our class doesn't create additional overhead:
[MethodImpl(MethodImplOptions.NoInlining)]
public static Logger GetCurrentClassLogger()
{
#if SILVERLIGHT
StackFrame frame = new StackTrace().GetFrame(1);
#else
StackFrame frame = new StackFrame(1, false);
#endif
return globalFactory.GetLogger(frame.GetMethod().DeclaringType.FullName);
}
Personally, I avoid tying any logging framework to my code by using
TraceSource to instrument my code. I then use a logging framework (typically Enterprise Library's Logging Application Block) to "listen" to trace output at runtime and do whatever is necessary with that information. (i.e. write to a database, send emails, etc)