<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 23, 2008, at 5:11 PM, Brian Stansberry wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Jay Balunas wrote:<br><blockquote type="cite">The threshold you're referring to should be the exception not the rule. I'll admit I have not been following all of this closely, but I thought the only reason we did not set logging to INFO by default was because CI builds need to have DEBUG set.<br></blockquote><br>As much as anything it was a timing issue. I made it controllable via a system property pretty shortly before AS 5 GA, when we were struggling to get valid testsuite results, QA lab was being shut down for days at a time etc etc. Changing the default to INFO would have meant ensuring all the various server configs we use in AS, EJB3, TCK tests etc were tweaked to run at DEBUG. Just one moving part to many.<br><br><a href="https://jira.jboss.org/jira/browse/JBASM-25">https://jira.jboss.org/jira/browse/JBASM-25</a> will make all that easy, but that would have required another server-manager release, which wasn't in the cards.</div></blockquote><div><br></div>I understand about timing ;-) thanks for the info</div><div><br><blockquote type="cite"><div><br><br><blockquote type="cite">I'm still confused why we don't just set a default value in log4j config file for the log setting to INFO. Since I can see the need to have a scriptable (i.e. command line) way to override for CI builds the we can use the ability to override via command line ( which I thought log4j supported anyway ).<br></blockquote><br>If you know another better way to meet the requirements, please describe it in detail or better yet implement it. :-)</div></blockquote><div><br></div><div>One way this can be done is<font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;"> to have a separate jboss-log4j-debug.xml file that contains the desired debug logging, then when starting JBoss use "</span></font><span class="Apple-style-span" style="white-space: pre; "><font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;">-Dlog4j.configuration=</span></font><span class="Apple-style-span" style="white-space: normal; "><font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;">jboss-log4j-debug.xml"</span></font><span class="Apple-style-span" style="white-space: pre; "><font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;">. In hudson this can be done by updating the the start shell command. </span></font></span></span></span></div><div><span class="Apple-style-span" style="white-space: pre; "><font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;"><br></span></font></span></div><div><span class="Apple-style-span" style="white-space: pre; "><font class="Apple-style-span" color="#00000000"><span class="Apple-style-span" style="background-color: transparent;">I was hunting for a way to update the log level directly via -D but could not find it. I thought there was a way, but the separate config file might be a better way anyway ;-)</span></font></span></div><br><blockquote type="cite"><div><br><br>Darran - good point that having a Threshold set but leaving it at DEBUG really gains nothing but adds an extra step to turning on TRACE logging. Don't see why you'd muck with the system property to enable TRACE logging on a running server though; just change the threshold from "${jboss.server.log.threshold}" to "TRACE".<br><br>Re: cost of isDebugEnabled() I proposed controlling the value of the org.jboss category via the same jboss.server.log.threshold property. Any comments?<br><br><blockquote type="cite">Parting thoughts before the holidays ;-)<br></blockquote><blockquote type="cite">-Jay<br></blockquote><blockquote type="cite">On Dec 23, 2008, at 12:53 PM, Darran Lofthouse wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">One drawback of this new Threshold is that to enable TRACE logging you are forced to set the property -Djboss.server.log.threshold=TRACE as even if this property is not set TRACE logging will be disabled just by the presence of this setting.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Secondly I don't believe this is going to cause isDebugEnabled() to return false as the category is still set to the default so expensive operations wrapped by isDebugEnabled will still be called.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Brian Stansberry wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="https://jira.jboss.org/jira/browse/JBAS-6205">https://jira.jboss.org/jira/browse/JBAS-6205</a> is done.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Shelly, if there is going to be a new server-manager release, how about we add a -Djboss.server.log.threshold=DEBUG to the args that get passed when an AS is started? That's a quick way to ensure testsuite configs launch with the correct level if we move the default to INFO. Otherwise we'd have to figure out all projects that use server-manager and edit their build file server:config elements.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Jay Balunas wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">OK thanks for the update. This property should make it very easy to adjust this for the test environment while still allowing us to ship AS5 in a configuration that does not created MBs of logs.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Nov 17, 2008, at 3:13 PM, Brian Stansberry wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Jay Balunas wrote:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">----- "Brian Stansberry" <<a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a>> wrote:<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I see 3 different issues here:<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">1) Code that does per-request logging at DEBUG level instead of TRACE.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">That's in violation of the logging standards and should be fixed.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">+1 and that is what we are seeing to some extent. We don't regularly need to known every time a class is loaded, or a persistence connection is closed.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">2) How much we log at DEBUG as part of service startup/shutdown. IMHO, this is not a huge problem. We should probably clean it up some, but<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the point of the logging is to make problem diagnosis easier, not to produce small logs for infrequent events.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Start up time in no little issue, but in general I agree. if there is extra logging during start up thats fine. The real issue is the reoccurring logs<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">3) The default loggging level for server.log. If #1 is broken, then having it be INFO makes sense, otherwise we punish users for our problems. If #1 is fixed, then different people can have different preferences, which I expect we're about to debate here. :-) My<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">personal one is to leave it at DEBUG, unless we can make it configurable via system property substitution. Otherwise all testsuite runs will log<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">at INFO unless we introduce testsuite hacks to replace the logging conf.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">IMO - I would like to see it at info, and use an ant command to adjust the debug level for hudson builds. Why punish our users so that the continuous builds log enough.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Log4j supports a basic system property substitution, so the server.log logging level can be controlled that way. I'll selfishly add that -- since it will help Bela in some stuff he's doing this week that in turn helps me. ;)<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="https://jira.jboss.org/jira/browse/JBAS-6205">https://jira.jboss.org/jira/browse/JBAS-6205</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Note that JBAS-6205 doesn't include changing the default to INFO. I think INFO's fine, but it's not my call and in any case it's a separate JIRA that involves some extra work (to get the testsuites to log at DEBUG).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">-- <br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Brian Stansberry<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Lead, AS Clustering<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">JBoss, a division of Red Hat<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><br><br>-- <br>Brian Stansberry<br>Lead, AS Clustering<br>JBoss, a division of Red Hat<br><a href="mailto:brian.stansberry@redhat.com">brian.stansberry@redhat.com</a><br></div></blockquote></div><br></body></html>