Today I decided to take matters into my own hands and get jul-log4j-bridge to work in my JBoss 3.x environment. The experience so far is: (A) jul-log4j-bridge plus the "apache-log4j-component" library seems unmaintained and I've seen a question asked of it on a list not get responded to (that I had the same question for when following the basic instructions). So I have some snapshot jars which were hard to find too. (B) I had to write code to make this work. I had to extend JBoss' Log4jService in order to trigger some special Log4j initialization code ( http://www.mail-archive.com/[EMAIL PROTECTED]/msg09043.html ) so that the log4j plugins are enabled. (C) I had to update the log4j-boot.jar of JBoss to the latest Log4j-1.2.15 (nothing less will do). There appears to be no ramifications thus far. Not a big deal
Now that I've crossed those hurdles, I'm wondering if there are down sides I am unaware of with regards to questionable / unknown quality of jul-log4j-bridge. Henri, have you found any such concerning info? I thought of using Tomcat's Juli but I don't want to use JUL, I want to use Log4j. ~ David Henrib wrote: > > The fact remains, there is still no solution available for those of us > trying to embed/deploy Solr in log4j-aware apps/environments besides > developing/deploying container-specific code. I still hope this community > can propose a better compromise. > If I had found the > http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/ > jul-to-log4j bridge to be a usable solution (or any other for that > matter), I would have avoided the -so far- sterile debate. > FWIW, solr-549 is using JUL -the API does not change- and, on principle, > this is not a log manager of sort but merely a thin proxy (look at the > code). > -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p16992281.html Sent from the Solr - Dev mailing list archive at Nabble.com.
