Develop Reference

who is reading logback.xml

Good day,
I have a existing Java web application host by websphere developed by senior, that using org.slf4j.Logger for logging. And I found that I have a logback.xml in my workspace, I do some changes on the logback.xml and its take effect.
However, I am curious which file is reading this logback.xml, I search for whole workspace, didnt found any place that is point to logback.xml.
I try to google on this, some is code to read this file, but didnt see any case like mine.
It it read by the the org.slf4j.Logger jar file?
Kindly advise.

You're already looking to the right direction. The configuration is read by logback (how this is done is described on a high-level here at the logback documentation). So the loading of the configuration happens in logback but not in slf4j (which is "just" a facade for different logging frameworks like log4j or in your case logback) as you suspected. Find some more details about SLF4J and the relation to logback here.
Hope that makes it a little more clear.

How do I learn how to use slf4j?

I asked a question earlier today about log4j and was told that it is now "legacy" and that I should use slf4j and logback. So now I will use that but I don't understand where to start? slf4j is a abstraction layer over other logging frameworks after what I read but I can't find anything other than really basic hello world logging tutorials? How do I configure slf4j and use it?

Slf4j is the API and yes logback is probably the implementation that you want.
Just use the slf4j logger classes in your code and the add logback.jar and logback.xml to your classpath.
The logback homepage contains a lot of the information you need to get started.

You will be using slf4j with log4j (or any other logging implementation). So if you use log4j with slf4j you will have to provide the configuration for log4j in the log4j.properties. So the advantage is if you want to later change to Logback, you just have to replace the binding jar file(for log4j it may be slf4j-log4j12-1.6.6.jar) with new binding jar and add the configuration for Logback. No change in code.
This thread should help you.SLF4J Manual

LOG4J as a singleton, anyway to avoid log4j logging conflicts in web environment

We have a j2ee web environment. The server is configured to share session and possibly classloaders across multiple webapps. Basically, one classloader could server multiple web apps.
This seems to cause issues with log4j. Different webapps could have different log4j configurations but the logging will move to the same file.
Reading online, it looks like log4j uses singletons a lot, in terms of the appenders and other functionality.
Is there a way to completely separate the log4j configurations from one webapp from the other.
Server: websphere6+
Log4j: 1.4.2
Java: 1.5
Example log4j.properties (webapp1):
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=/usr/local/file1.log
log4j.additivity.com.app=false
Example log4j.properties (webapp2):
log4j.appender.Z=org.apache.log4j.RollingFileAppender
log4j.appender.Z.File=/usr/local/file2.log
log4j.additivity.com.app=false
Right now, logging from webapp2 may appear in the webapp1 logs and vice verse. We don't want that.
Possible Solution:
It might be possible to add a custom file appender? Would that fix the issue and what code would I add to the custom appender?
Is it possible to change the log4j initialization. E.g., could I use some startup servlet to load logj4 for each webapp.

You have two ways to solve your problem:
Configure your app. server so it doesn't share classloaders across multiple webapps. When it does do that, because of log4j's nature, only one log4j.properties file will be loaded.
If you leave the app. server so it shares classloaders, then use one "master" log4j.properties file. In it, define appenders for root of every one of your applications (example com.mycompany.webapp1, com.mycompany.webapp2)
No solution is perfect. Particularly, the second one will be problematic if your web apps share some classes that use log4j. In that case, logs from both apps will end up in the same file.
Your problem is a common one. To understand more about this topic, google for "log4j and j2ee".
Edit: since solutions 1 and 2 aren't feasible, you could try something else:
Use log4j.properties file per application. In every one of them, define an appender for their root (as explained in solution 2), and set additivity to false. This also won't be perfect if there is any class sharing between them.
Configure log4j programatically for every application. Since they're legacy applications, this could be tough. One way to do it is to use ServletContextListener for every application and configure log4j on application startup. I haven't personally tried this, so I'm not 100% sure if there will be clashes due to shared classloaders.
Log4j won't be really updated anymore. Ceki Gülcü, who created log4j, stated that he will focus his efforts on slf4j and logback, to correct some mistakes he did during development of log4j.

log4j.xml in client jars

I have some jar files that will be distributed to clients that are using log4j for logging. My question is should I include a log4j.xml configuration in the jar file or have the client provide one if they want logging?
My feeling is to leave the log4j.xml configuration file out of the client jars, since the apache jar files all come with log4j logging, but sans log4j.xml.

Yes, leave it out. It's an utter nuisance when your log4j configuration file is ignored because one of the 60 third-party libraries of your app contains its own.

The good thing about log4j in your case is that your jar really shouldn't have to worry about it. The basic use case of log4j is:
Obtain a logger object for the current class
Call one of the methods on that logger, such as debug("some message");
If the jars you are shipping are to be used by a larger application, then ideally your code will only do the two steps listed above. In this way, your code will simply obtain logger objects from the already-configured log4j instance in the client's application. Your production code is then decoupled from having to know how to configure log4j.
Any logging you need to see for your development of the jars can be accomplished by configuring a log4j instance in unit test setUp() methods or something similar that won't get bundled with the production code going to the client.

I would put a default log4j configuration that you expect will be useful to your clients in the documentation. This way interested people can see what logging options you have (usually certain classes have more interesting log messages, from the user's perspective). I find it annoying when I have a third-party lib using log4j and it has no documentation, and there are log messages filling my screen and I have to try to figure out how to enable or suppress certain log messages.

If you are using log4j in your application then you include it in your project. If you are not, then why would you put it in there? What if client A wants log4j version 1.2 and client B wants log4j version 1.3.
Let them decide what they need for their projects and worry about what you need for yours.

I would add the configuration xml and load it up with instruction for the user showing different configuration and options. This will make it easier for either them or support to enable addition logging.

How do I unify logging formats from the java stack

Using a Jetty web server, started from maven, which includes iBatis, Spring, Jersey, a little of this and a little of that, I get logging output with a host of formats.
Some are from maven:
[INFO] [war:war]
[INFO] Exploding webapp...
Some are from Jetty:
2009-03-25 21:01:27.781::INFO: jetty-6.1.15
2009-03-25 21:01:28.218:/example:INFO: Initializing Spring root WebApplicationContext
Some are from Spring:
INFO ContextLoader - Root WebApplicationContext: initialization started (189)
INFO XmlBeanDefinitionReader - Loading XML bean definitions from ServletContext resource [/WEB-INF/applicationContext.xml] (323)
Some are from Jersey:
Mar 25, 2009 9:01:29 PM com.sun.jersey.spi.spring.container.SpringComponentProviderFactory register
still others are from my code:
INFO ExampleApp - [User#14ef239 ...stuff] (69)
I expect they're all using standard logging packages (log4j, commons-logging, java-logging...)
Is it possible, and what is the easiest way to configure all of them to use the same format?
Is there any benefit to leaving them in varying formats?

This is possible using the logback library and its bridges. It basically consists to remove any log4j commons or alike jars from the classpath, stick logback jar file and bridges jars for log4j and alike. Spring, jersey and maven will use the bridge factories to instantiate loggers which in turn will use logbak producing unified logging.
Check http://logback.qos.ch/ and http://www.slf4j.org/legacy.html
The key are the bridges which link other log utilities with a single global logger.

The issue you have is that the applications are using different logging libraries. Jersey will use JUL, Spring will use commons-logging (which will in turn pick log4j if that's in your classpath), and Jetty uses its own logger. You can fix this by getting all your components to log through JUL.
First you need to get log4j off your classpath. Use exclusions or other mechanisms to ensure that log4j is not included. This will prevent commons-logging from picking log4j over JUL and get Spring to log in the same format as Jersey.
Next you'll need to configure Jetty to use commons-logging. You can find information about that on the Maven Jetty Plugin documentation page.
If your application code is using log4j directly, you'll need to switch to either commons-logging or JUL.
Maven I'm not so sure about, but it probably has a similar solution.

I don't know of any way to manage what you're describing in a useful manner. If you're desperate, the best suggestion I can make is to write something to unify the disparate formats under one umbrella and manage it there using your preferred logging format.

I don't think you can unify all of these easily, because you don't know what is being used by each framework.
If you identify which ones you are interested in then you can get each to output to log files in a central location /var/log/app (under linux for example). From here you could write a simple utility that parses each log file and massages the data into a single log file in the format that you want. The Awk utility is very good at doing this sort of thing.
Alternatively, you could leave them as they are - and use something like Splunk to index the files for future searching and analysis. It really depends on what you require from the log files at a later date. Hope that helps.

If and when they are using standard logging package, of course you can unify common parts ("INFO" prefix, timestamp, category name (usually class/package)). Just configure log4j / J.U.L / logback to your liking.
I don't know why you would get different formats -- log formats are NOT configured by frameworks, but apps -- so maybe they are using different frameworks. But that may be accidental.
As to whether it matters; well, only if you process it automatically (trigger regex-based alarms).

SLF4J allows you to consolidate logging by routing it into a single logging framework. You can redirect legacy logging calls made with commons-logging, java.util.logging and log4j as if they were made to SLF4J. See www.slf4j.org/legacy.html for details.
All logging will then be delegated to an underlying framework of your choice, for example logback, log4j, java.util.logging among others. If you run into trouble do contact the slf4j-user mailing list.

I think we will eventually need a "logging api" logging api that ties together all unified logging apis such as slf4j and whatever other ones they are. Who knows, you might need to change your logging framework that handles all types of logging one day...

Simply use http://logback.qos.ch/translator/ to convert the log4j.properties into xml format and paste that in logback.xml. This works as charm directing your log to appender configured.