David Smiley @MITRE.org wrote: > > (A) jul-log4j-bridge plus the "apache-log4j-component" library seems > unmaintained > (C) I had to update the log4j-boot.jar of JBoss to the latest Log4j-1.2.15 >
I went more or less through the same path; I did "custom" build the bridge by stripping the needed components and it indeed requires log4-1.2.15. David Smiley @MITRE.org wrote: > > (B) I had to write code to make this work. > Which is precisely what I am trying to avoid; having to write code specific to each container & deploying it in its own specific way. In the environments I usually have to work with, it is very hard to justify what they call a "one-off configuration" for any webapp; there is a standard configuration defined by IT and you got to work within their rules. This allows them to easily replicate environments and avoid maintaining specific webapp knowledge. Which implies the .war must contain everything needed, its own (logging & al) configuration included. What you are going through should not be necessary <rambling>especially considering the cause of the problem & the fact that we have solutions...</rambling> David Smiley @MITRE.org wrote: > > 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? > My take is that the bridge behavior is very dependant on the LogManager implementation and configuration which is "so-so" for a generic solution. YMMV. The bridge basically hijacks the configuration to put its own handler which is not guaranteed to be always possible or working. My own quest started from a Websphere deployment; in the WAS env, all loggers (except anonymous ones) will anyway log to the main logging facility (and these are the logs that the customer is complaining about, other apps/modules use log4j). So, bridge or no-bridge, I can't really redirect this logging output; can't even shut it down by forcing a readConfiguration... There are also some operations that may fail for security reasons if a security manager is in place; when the whole JUL configuration is shared (not per webapp), this is to be expected. On the nitpicking side, I also had to tweak a bit the handler to get file/line in log4j which I find convenient in debug (see the event converter code in solr-549). My take is that a fully generic bridge needs to be a JDK LogManager... -- View this message in context: http://www.nabble.com/Solr-Logging-tp16836646p16993247.html Sent from the Solr - Dev mailing list archive at Nabble.com.
