I have spend several hours on the last few days to integrate SLF4J with logback in tomcat 6.0.32 ;
My use case is that I want to use slf4j and logback to process all log from tomcat, associated libraries, logback-access and several webapps, each of those webapps having their own configuration file.
I came to logback hoping to have a better experience than with log4j regarding (advertised) context separation and co, but it have been quite more painful than expected.

I have used the solution posted here
https://github.com/grgrzybek/tomcat-slf4j-logback
which is very useful (thanks!) but still suffer from multiple inconveniences.

• It's a bit of a hack ; a very nicely packaged one, but still, having to relocate the package to another namespace and having two copies of the framework is not a smooth integration.
• if you want both tomcat internal -> slf4j -> logback and logback-access, you end up with copies of logback-core and logback-classic in lib/ and suffer from context leakage between webapps which target the common jar
• if you tries to circumvent the former problem with the use of the context JNDI selector, it is picked also by the package relocated tomcat-logback used for internal tomcat logging and go to a bootstrap issue with naming services since it is called early in tomcat start sequence. One could try to patch more the relocated package to rename the property name used to set context selector, but it is adding more complexity and renaming to the relocation hack
• I ended up adding logback-access to the package relocation build and use the renamed version ; it works but hardly elegant and still does not solve other problems.
• If your have an endorsed/ dir in tomcat with some libraries, coming say from apache foundation, that use commons logging, the jcl-slf4j bridge works well but you end up with slf4j and logback in endorsed/ and you also say good by to free context isolation by webapp classloader and copies of logback in each webapp.
• to be sure to choose the good logback configuration for a webapp, I used the ServletContextListener from LBCLASSIC-202 ; a good solution but requires more packaging since it's not present in standard distribution.

I think it could work better with the availability of a bit more Context selector logic, but before digging further, i'm interested to know if there is some work going on in those areas, which I would prefer not to duplicate.