In my project, services will be shared among online transactions and batches.
I want the logs written by the same logging statement in a service to be separated to two different log files for online and batch. How can that be done?
In my project, services will be shared among online transactions and batches.
I want the logs written by the same logging statement in a service to be separated to two different log files for online and batch. How can that be done?
This really hasn't anything to do with the Spring Batch project.
The answer is related to your logging framework. In Log4j and Logback you have something called a MDC, there you can set (per thread/per...) some settings which also get printed in the logfile. logback
Marten Deinum
Java Consultant / Pragmatist / Open Source Enthousiast / Author
Pro Spring MVC: With Web Flow
Conspect
Have you read the reference guide.
Use the [ code ] tags, young padawan
When the logs are being written by multi-thread processes during batch, is it possible that it would cause contention. Or log4j has its own mechanism to address that?
You could have a look at the following:
http://logging.apache.org/log4j/docs...cAppender.html
blog: http://pveentjer.wordpress.com project: STM Implementation http://multiverse.googlecode.com
Is AsyncAppender a singleton thread inside the system?
Will it queue the logging events internally such that no concurrent logging will occur to the same log file in the same moment?
Imo - high (high meaning hundreds of thousands of messages per day) throughput/ high concurrency systems shouldn't use detailed levels of logging. If you need audit for all the messages you shouldn't rely on logging.
Anyone knows if I can use AsyncAppender in J2EE/ Websphere environment? I read the source code that it will spawn thread on its own.
Will the threads not being managed by Websphere cause issue?
Might be a problem (IBM would certainly not be happy about it), but in practice probably not. If you want to be cautious you would have to write your own appender using CommonJ (or proprietary IBM APIs).