Wow, thanks very much for this very long and detailed answer Howard, very useful information. It seems that your last point is most pertinent to my position, in that I that have classloader isolation enabled (I always wondered why I still had to remove my local Hibernate\JPA library in this mode) and the cas-server-webapp log4.xml is working, except it prevents any log output, including from JBoss, from being output to the Console and it all goes to cas.log, which is not so good when developing.
I will look into the RepositorySelector and see if it will help. Thanks very much AB On 21 November 2010 15:48, Howard Gilbert <[email protected]> wrote: > Log configurations are a static feature of the log4j classes. The slf4j and > log4j JAR files are in /commons/lib and are normally shared by all contexts, > so in this arrangement everyone shares the JBoss common logging configuration > and any local log4j.xml file is ignored. > > If all that CAS used was log4j, then all you would have to do is configure it > to run in J2EE standard mode where a ClassLoader searches WEB-INF/lib before > /commons/lib. Then a local log4j JAR would be found first, and you could have > your own local logging environment. Unfortunately, parts of CAS use the slf4j > facade. When it initializes, slf4j searches for a "provider" and is only > happy if there is only one provider in the entire classpath. Since JBoss 5 > has a jboss-slf4j logging provider in commons/lib, you cannot initialize your > own slf4j environment as long as /commons/lib is visible in the classpath at > all. Just searching commons/lib after WEB-INF/lib is not good enough, because > slf4j will still find that there are two providers somewhere in its > classpath. So standard J2EE classloader semantics work for naked log4j but > not for slf4j, and some of CAS uses slf4j. > > I know there are articles that suggest that classloader isolation mode can > exclude /commons/lib all together, but that doesn't make any sense at all. > Applications simply don't work unless they get access to the particular > Hibernate and JSF classes that the container provides, and unfortunately it > provides logging classes in the same place. In particular, if you use JBoss > Cache clustering you are out of luck if you cannot get to the particular > Cache JAR in commons/lib. > > The solution is a feature built into log4j called a RepositorySelector. It > was specifically added to handle situations like JBoss. When you issue a > log.info("...") statement, internally the code selects a Repository which is > basically a hierarchical set of object built from a log4j.xml file. By > default, everyone shares a single Repository through a static pointer, but > container providers like JBoss can override the RepositorySelector to select > a specific log4j.xml configuration set of objects based on the context that > is issuing the log statement. > > If you Google for JBoss and RepositorySelector you may find some sample code > in the JBoss Wiki that has been around for several releases and allows you to > create custom log4j configurations for individual JBoss applications. You > are, of course, hacking JBoss but you are using some code they provide as the > example. > > (Un)Fortunately, this will be fixed in JBoss 6, which goes CR1 any moment now > (was supposed to be out last Monday and is late). According to JIRA at least, > the previously published example RespositorySelector was integrated into > JBoss 6 since M4 and will be part of the new release. The documentation may > trail some, but eventually each application will be able to have its own > log4j.xml file that will actually work even though you are sharing > commons/lib JAR files. > > Meanwhile, if you try isolation and end up in a situation where your log4j is > working, except that it is not logging to the Console, remember that from the > class point of view "the Console" is System.out, and there are mechanisms for > a container to provide a context with its own System.out specifically so it > cannot mess with the container's own Console messages. You have to accept > that logging to the real console may be prohibited no matter how you try to > do it, unless you use the jboss-log4j.xml common shared logging > configuration/repository. > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
