What is the right logging approach when using Spring Batch? Should I use log4j (or something similar) or Spring Batch provides some instruments that help me to instantiate a logger and use it? Maybe some sort of dependency injection of the logger?
I'd used log4j. and its the simple and nice approach.
I'm not sure the original poster's question was answered, so I'll try restating this a bit. In Spring Batch you may have multiple threads going, and you may want to have job-specific logging, so that all events for a particular job are logged into a single log file. You want a Logger whose scope is tied directly to the job you are processing. When the job finishes, the logger (and all references to the logger) go away.
So when you submit Job#1, all events are logged to "job_1.log"; when you submit Job#2, its events are logged to "job_2.log", etc.
In log4j, when you do "Logger.getLogger('mylogger')" you are telling the LogManager to get 'mylogger' out of the cache and give it to you. What you really want is a new instance of the logger, configured using the configuration of mylogger. In Spring this might be typically done with a prototype bean. Every time you ask the context for 'mylogger' you would get a new instance.
You should think about Slf4J (logging API) + Logback (logging implementation) as Log4j is intented to be succeeded by this duet.
More:
http://www.slf4j.org/
http://logback.qos.ch/
Related
I would like to inject a piece of information into all messages logged by anything, including third-party code. The reason is that, in our web-services-oriented application, requests come in with unique IDs and I want those unique IDs to be attached to all log messages that occur while processing a request, to assist in later analysis. I am already tracking the "current request" using ThreadLocal<> techniques, so I have the ability to fetch the "current request" from anywhere.
To that end, I would like to configure log4j such that I can inject the requestID into messages before they reach the root logger (or appender?). I know that I can just make a whole new Appender that implements append() and does whatever it wants with the output, but that's not what I'm asking for. I want output to ultimately go to whatever appender is configured at startup, but with the additional information attached.
I am using log4j 1.x, but if a move to log4j 2.x or using slf4j makes this significantly easier, I would consider it.
Is it possible to transfer the AEM (v5.6) logs to the Log4j server? Or there is some best practice for centralized AEM logging?
I haven't dealt much with AEM. It seems the Apache Sling Logging services configure only the FileAppender.
For CQ5.5 there is no log4j.xml. All the CRX logger needs to
configured using sling config.
We can use Apache Sling Logging Logger
Configuration
(https://docs.adobe.com/docs/en/aem/6-0/deploy/configuring/monitoring-and-maintaining.html#Create%20a%20Custom%20Log%20File)
or LogBack
(http://sling.apache.org/documentation/development/logging.html#logback-integration)
AEM provides the loggers out of the box as you have seen. Typically if you want centrallized log handling I would suggest mounting a super-high-speed shared volume and having all instances log there, just for performance/speed reasons.
You might want to check out this:
http://adobe-consulting-services.github.io/acs-aem-commons/features/syslog-appender.html
It is AEM6 only, but you could look at the code and do it that way.
This uses logback, not log4j, but it should solve your problem.
The other option, really, is to write your own logging service and use that and configure the appender in the code. I do not see the normal XML files anywhere. I'm curious if you come across them.
Let me know if I can help further.
I'm looking for a way to define transitive log message routing. Let's say we have an application called poly with these packages:
com.mycompany.server-common
com.mycompany.communication
com.mycompany.webservice
server-common is used by both of the 2 others. All 3 use org.hibernate as well.
Now, I like to have 1 logfile for the webservice component with all messages from com.mycompany.webservice and with those messages from com.mycompany.server-common and org.hibernate that were initiated by the webservice. And then, another coresponding file for the communication package.
My application is a war file running in tomcat, where all components run in 1 context (it comes in 1 war file). I already defined the multiple log files, but they naturally only log that what i defined statically, there is no transitive inclusion.
I would be very interested in ideas how I could achieve the desired behaviour. I already thought about using the MDC for that, but I'm not sure if that's a good idea.
Another idea was to separate the contexts, but I think in the current project state this will be hard and it does not offer the flexibility I hope for.
Any hints or discussions are appreciated.
If you set an MDC key when webservice starts serving a request and clear the MDC key at the end of the request, SiftingAppender will do what you are asking. Shout on the logback-user mailing list if you run into difficulties.
There is only one file. And it is written simultaneously as web app copies run.
How do you filter only one session log messages from other log lines?
Using a servlet filter with either NDC or MDC information is the best way I've seen. A quick comparison of the two is available at http://wiki.apache.org/logging-log4j/NDCvsMDC.
I've found MDC has worked better for me in the past. Remember that you'll need to update your log4j properties file to include whichever version you prefer (pattern definitions at http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html).
A full example of configuring MDC with a servlet filter is available at http://veerasundar.com/blog/2009/11/log4j-mdc-mapped-diagnostic-context-example-code/.
A slightly easier to configure, but significantly inferior option: You could opt to just print out the thread ID (via the properties file) for each request and make sure that the first thing you log about each request is a session identifier. It isn't as proper (or useful), but it can work for low-volume applications.
You could set a context message including the identifier of the specific app instance using org.apache.log4j.NDC, like this:
String appInstanceId = "My App Instance 1";
org.apache.log4j.NDC.push(appInstanceId);
// handle request
org.apache.log4j.NDC.clear();
You can set up the context during the initialization of your web app instance, or inside the doPost() method of your servlets. As its name implies, you can also nest contexts within contexts with multiple push calls at different levels.
See the section "Nested Diagnostic Contexts" in the Log4J manual.
Here is a page that sets up an MDC filter for web-app -> http://rtner.de/software/MDCUserServletFilter.html
Being a servlet filter it will free you from managing MDC/NDC in each of your servlets.
Of course, you should modify it to save information more pertinent to your web-app.
If you want to differentiate sessions in the same application then the MDC is the way to go. But if you want to differentiate the web applications writing to the same file, then MDC won't help because it works on a thread basis. In such case I used to make my own appender which knows which application instance it serves. This can be done through appender configuration properties. Such appender would stick application name into each logging event as a property before writing it into the media, and then you can use a layout to show this property value in the text file it writes to. Using MDC in such case won't work because every thread will have to MDC.put(applicationName) and that is quite ugly. MDC is only good for single process, not for several processes. If someone knows the other way, I'd like to hear.
In the majority of cases I see Log instances declared as follows:
public static final Log LOG = LogFactory.getLog(MyClass.class);
I assume this means that the log configuration is loaded when the MyClass is loaded and is therefore set in stone until the MyClass is either reloaded or the JVM restarted?
So, if this assumption is correct what is the best way to ensure changes to the log configuration are picked up as (or as soon after) they happen?
I assume that you are using commons-logging from the LogFactory class? As far as I know, none of the usual logging implementations (Log4J, java.util.logging) allow you to reload a configuration file in a running application (regardless of whether the actuall Loggers are declared as static variables). (EDIT: Peter's answer below proves that I was wrong about this in the case of Log4J)
However, they do allow for the dynamic changing of logging levels (e.g. via an MBean). These level-changes will be picked up by any Logger (including those declared as static variables). If you use java.util.logging you get the MBean for free in the JConsole.
Is it just the changing of levels you care about, or do you wish to provide completely different logging configurations (e.g. files, logger definitions) on the fly?
I guess this depends on the underlying implementation, as pointed out by oxbow_lanes. Generally, it might be difficult to reconfigure your logging subsystem if you are relying on config files that are available via the classpath. To get around this limitation, we do all our config programmatically, and do not rely on only static config files. But I don't know whether your implementation support programmatic reconfiguration.
No, the log configuration is loaded typically when the logging implementation classes are initialized. When your class is (re)loaded, all that happens is that the logging API is called to get a logger (which may or may not be present in any configuration) and stored as a class variable.
To reload your logging configuration, then you typically would have to get the logging implementation to reload.
Depends on the backend.
Logback has a very niftly feature where the reload can be triggered by JMX, i.e. in jvisualvm or jconsole.
Actually, if you are using "java.util.logging" logging directly, then you CAN reload the logger configurations on the fly. There are two methods on the LogManager class for doing this:
public void readConfiguration()
throws IOException, SecurityException
This reloads the default logging properties and reinitializes the logging configuration.
public void readConfiguration(InputStream ins)
throws IOException, SecurityException
This loads the logging properties from a stream (in Property file format) and reinitializes the logging configuration.
See the LogManager javadoc.
Log4j can reload your config file whenever it changes.
see the faq here
Is there a way to get log4j to
automatically reload a configuration
file if it changes?
Yes. Both the DOMConfigurator and the
PropertyConfigurator support automatic
reloading through the
configureAndWatch method. See the API
documentation for more details.
Because the configureAndWatch launches
a separate wathdog thread, and because
there is no way to stop this thread in
log4j 1.2, the configureAndWatch
method is unsafe for use in J2EE
envrironments where applications are
recycled.