http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14324 https://issues.apache.org/bugzilla/show_bug.cgi?id=45753 Summary: Code contribution Product: Log4j Version: 1.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Other AssignedTo: log4j-dev< at >logging.apache.org ReportedBy: chad_lavigne< at >yahoo.com Created an attachment (id=22533) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22533) Logging filter to regulate log message bursts I've written a filter to regulate logging traffic bursts that I'd like to have considered for contribution. It's useful for situations where you may want to limit the number of logging messages that are sent to an appender, i.e. when the database goes down you don't want 2 million e-mail logs taking out the mail server. It looks like no further development is planned for 1.2 except for bug fixes and minor enhancements. Is this feature small enough to be considered a minor enh bugzilla< at >apache.org 2008-09-06T17:09:23 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14323 Author: carnold Date: Sat Sep 6 09:20:38 2008 New Revision: 692676 URL: http://svn.apache.org/viewvc?rev=692676&view=rev Log: Bug 44386: Restoring exception out of static initializer when missing dll, relocating prebuilt amd64 Added: logging/log4j/trunk/NTEventLogAppender.amd64.dll (props changed) - copied unchanged from r692580, logging/log4j/trunk/src/ntdll/resources/NTEventLogAppender.amd64.dll Removed: logging/log4j/trunk/src/ntdll/resources/ Modified: logging/log4j/trunk/src/assembly/bin.xml logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java Propchange: logging/log4j/trunk/NTEventLogAppender.amd64.dll ------------------------------------------------------------------------------ svn:mergeinfo = Propchange: logging/log4j/trunk/NTEventLogAppender.amd64.dll ------------------------------------------------------------------------------ svn:mime-type = application/octet-stream Modified: logging/log4j/trunk/src/assembly/bin.xml URL: http://svn. carnold< at >apache.org 2008-09-06T16:20:40 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14322 Author: carnold Date: Fri Sep 5 16:35:09 2008 New Revision: 692580 URL: http://svn.apache.org/viewvc?rev=692580&view=rev Log: Bug 44386: Handle mapping approach for Win64, prebuilt amd64 dll Added: logging/log4j/trunk/src/ntdll/resources/ logging/log4j/trunk/src/ntdll/resources/NTEventLogAppender.amd64.dll (with props) Modified: logging/log4j/trunk/src/assembly/bin.xml logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java logging/log4j/trunk/src/ntdll/nteventlog.cpp Modified: logging/log4j/trunk/src/assembly/bin.xml URL: http://svn.apache.org/viewvc/logging/log4j/trunk/src/assembly/bin.xml?rev=692580&r1=692579&r2=692580&view=diff ============================================================================== --- logging/log4j/trunk/src/assembly/bin.xml (original) +++ logging/log4j/trunk/src/assembly/bin.xml Fri Sep 5 16:35:09 2008 < at >< at > -33,18 +33,18 < at >< at > <include>KEYS</include> <include>LICENSE</include> <include>NOTICE</include> -<include>cont carnold< at >apache.org 2008-09-05T23:35:09 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14321 On Sep 5, 2008, at 2:49 PM, Chad LaVigne wrote: Yes, but entering it in Bugzilla (http://issues.apache.org/bugzilla) is preferred. Many mailing list archives do not retain the attachments, so an Bugzilla entry from you with the source code attached has a better audit trail. You do have to first create the issue and then subsequently make the attachments. As for feedback, the previous weekend was a holiday in the US which may explain why your contribution didn't get much attention. Curt Arnold 2008-09-05T22:07:36 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14320 Author: carnold Date: Fri Sep 5 13:15:41 2008 New Revision: 692526 URL: http://svn.apache.org/viewvc?rev=692526&view=rev Log: Bug 44386: Partial revert of 687885 Modified: logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java logging/log4j/trunk/src/ntdll/nteventlog.cpp Modified: logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java URL: http://svn.apache.org/viewvc/logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java?rev=692526&r1=692525&r2=692526&view=diff ============================================================================== --- logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java (original) +++ logging/log4j/trunk/src/main/java/org/apache/log4j/nt/NTEventLogAppender.java Fri Sep 5 13:15:41 2008 < at >< at > -30,16 +30,14 < at >< at > <p><b>WARNING</b> This appender can only be installed and used on a Windows system. - <p>Do not forget to place an NTEventLogAppender.dll - or "NTEventLogAppender carnold< at >apache.org 2008-09-05T20:15:42 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14319 --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscribe< at >logging.apache.org For additional commands, e-mail: log4j-dev-help< at >logging.apache.org Chad LaVigne 2008-09-05T19:49:53 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14318 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #14 from Ceki Gulcu <ceki< at >apache.org> 2008-09-05 08:55:42 PST --- James Strachan has kindly contributed his patch to the logback project as well. See http://jira.qos.ch/browse/LBGENERAL-23 After spending several days working on this problem, I discovered that a one line change makes a big impact on performance. Replacing URL resource = type.getClassLoader().getResource( \ type.getName().replace('.', '/') + ".class"); with URL resource = type.getProtectionDomain().getCodeSource().getLocation(); My tests show 12 fold improvement in performance. The time it takes to handle a stack trace goes down from 5 milliseconds to 400 microseconds. The same code without James' patch, that is without package version extraction, takes 100 microseconds. HTH, bugzilla< at >apache.org 2008-09-05T15:55:43 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14317 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #13 from Curt Arnold <carnold< at >apache.org> 2008-09-04 21:08:26 PST --- From comment #12 AsyncAppender and the SocketAppenders call LoggingEvent.getThrowableStrRep() before queuing the logging event or sending it across the wire. The serialized form of the ThrowableInfo only contains the resulting string representation of the throwable. Any configured ThrowableRenderer would occur in this step which would be on the thread doing the logging and not in the dispatching thread or deserializing environment. The log4j 2.0 two pass approach of an extract phase during the call to extract value objects followed by a render phase, likely deferred, that only works on the extracted value objects should allow arbitrary formatting of the Throwable. However, the log4j 1.2 design limits the layout to working with the output of ThrowableInfo.getThrowableStrRep. Could prepend "org.apache.log4j." if Class.forName() can't find the class, so you c bugzilla< at >apache.org 2008-09-05T04:08:27 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14316 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #12 from Paul Smith <psmith< at >apache.org> 2008-09-04 15:32:48 PST --- (In reply to comment #11) This is technically true. The common case though is for the local appender to benefit from it. If we added a property to PatternLayout as James has done, it can be documented with the fact that the rendered string is only relevant to local environments. I'm not sure how this gets around your Chainsaw scenario at all, doesn't this suffer from the same problem? Anyway, I think this sort of problem just needs to be documented. Unless the serialized form of the ThrowableInformation can carry with it all the details of the classes at computation time so that it can be displayed on some remote end. That would change the payload weight of that class significantly though. I'm not sure that is going to be worth the cost/effort. I had always thought the Layout was responsible for emitting the Throwable string, but as I learnt yesterday work bugzilla< at >apache.org 2008-09-04T22:32:49 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14315 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #11 from Curt Arnold <carnold< at >apache.org> 2008-09-04 10:15:50 PST --- I've thought a little bit more of this on the drive back home and hope to look at the issue in detail in the next 24 hours. PatternLayout or EnhancedPatternLayout probably isn't the appropriate place for the enhancement since it may be in a totally different environment that the original caller. For example, if the LoggingEvent + ThrowableInfo has been serialized and sent to Chainsaw over a SocketAppender, you'd get the jar or version of the class in Chainsaw's environment. I'd leaning more toward trying to mimic the ObjectRenderer approach and allow you to either register a ThrowableRenderer class through a system property or configuration file. Something like: java -Dlog4j.ThrowableRenderer=org.apache.log4j.EnhancedThrowableRenderer The ObjectRenderer interface could be used for the ThrowableRenderer, but a new interface would likely be better. I'm guessing bugzilla< at >apache.org 2008-09-04T17:15:50 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14314 Hi, I am using JDBCPlus (http://www.dankomannhaupt.de/projects/index.html ) as a jdbc appender for my application. For a particular requirement, I have to make a column datatype from varchar2(4000) to CLOB. But as soon as I do this, my application fails to log in database giving stack trace as log4j:ERROR JDBCAppender::flush_buffer(), : java.sql.SQLException: Internal Error: Unable to construct a Datum from the specified input at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:210) at oracle.jdbc.dbaccess.DBError.check_error(DBError.java:829) at oracle.sql.SQLUtil.makeDatum(SQLUtil.java:645) at oracle.sql.SQLUtil.makeOracleDatum(SQLUtil.java:946) at oracle.jdbc.driver.UpdatableResultSet.updateObject(UpdatableResultSet.java:1568) at oracle.jdbc.driver.OracleResultSet.updateObject(OracleResultSet.java:2787) at org.apache.log4j.jdbcplus.JDBCLogger.append(JDBCLogger.java:742) at org.apache.log4j.jdbcplus.J Vaibhav Kumar 2008-09-04T09:36:18 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14313 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #10 from James Strachan <james.strachan< at >gmail.com> 2008-09-04 00:33:05 PST --- Paul, feel free to make those methods private if you like; I don't have a strong opinion either way :) Curt - if you wanna add support in the EnhancedPatternLayout please be my guest too; it should be pretty trivial either to reuse the same code on ThrowableInformation, or use JDK 1.4's getStackTrace() - as Paul said, the JDK has hard coded "at " so its no biggie either way really. I'm keen to ensure the core log4j package has support for this enhanced stack trace feature ASAP as its what most users seem to use. Until this thread, I'd never heard of or seen the apache-log4j-extras stuff :). But the more places that support this feature in the Java logging ecosystem, the better! bugzilla< at >apache.org 2008-09-04T07:33:05 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14312 https://issues.apache.org/bugzilla/show_bug.cgi?id=42171 --- Comment #14 from Paul Smith <psmith< at >apache.org> 2008-09-03 21:57:54 PST --- Checked in as part of revision 691872. Many thanks ray< at >! bugzilla< at >apache.org 2008-09-04T04:57:54 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14311 Author: psmith Date: Wed Sep 3 21:57:11 2008 New Revision: 691872 URL: http://svn.apache.org/viewvc?rev=691872&view=rev Log: Bug 42171 Applied patch supplied by ray< at > that resolves a bug where by duplicate events are received after a SocketHubReceiver is shutdown and then restartedi such as when used under Chainsaw. Modified: logging/log4j/companions/receivers/trunk/pom.xml logging/log4j/companions/receivers/trunk/src/changes/changes.xml logging/log4j/companions/receivers/trunk/src/main/java/org/apache/log4j/net/SocketHubReceiver.java logging/log4j/companions/receivers/trunk/src/main/java/org/apache/log4j/net/SocketNode13.java Modified: logging/log4j/companions/receivers/trunk/pom.xml URL: http://svn.apache.org/viewvc/logging/log4j/companions/receivers/trunk/pom.xml?rev=691872&r1=691871&r2=691872&view=diff ============================================================================== --- logging/log4j/companions/receivers/trunk/pom.xml (original) +++ logging/log4j/companions/receivers/tru psmith< at >apache.org 2008-09-04T04:57:12 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14310 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #9 from Curt Arnold <carnold< at >apache.org> 2008-09-03 21:54:41 PST --- The EnhancedPatternLayout in the extras (backported from log4j 1.3's PatternLayout) already has some support for configuration of stack traces by using the %throwable pattern specifier. You can already use %throwable{full} and %throwable{short} to specify the JDK generated stack trace or just the throwable's message, respectively. Adding support for {enhanced} and {none} (to suppress stack trace) would be fairly straight forward and could use JDK 1.4's getStackTrace(). Not sure how difficult that approach would be to add to log4j 1.2's PatternLayout since its parser wasn't designed for longer pattern specifiers. bugzilla< at >apache.org 2008-09-04T04:54:42 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14309 https://issues.apache.org/bugzilla/show_bug.cgi?id=42171 --- Comment #13 from Paul Smith <psmith< at >apache.org> 2008-09-03 20:30:52 PST --- Confirmed this new patch is working for me. I'll just do a quick code review and commit I think. bugzilla< at >apache.org 2008-09-04T03:30:52 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14308 https://issues.apache.org/bugzilla/show_bug.cgi?id=42171 ray< at >itasoftware.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #22481|0 |1 is obsolete| | --- Comment #12 from ray< at >itasoftware.com 2008-09-03 20:25:43 PST --- Created an attachment (id=22523) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22523) corrected patch Basically the same patch as before, but starting from the correct code (I think). bugzilla< at >apache.org 2008-09-04T03:25:44 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14307 https://issues.apache.org/bugzilla/show_bug.cgi?id=45721 --- Comment #8 from Paul Smith <psmith< at >apache.org> 2008-09-03 15:35:21 PST --- This looks really good James! My only question is with regards to the extra methods in ThrowableInformation that are marked as protected, is there a need to keep them protected rather than make them private? I can't think of a reason to expose those methods in the public api, that's not to say there isn't one, and certainly with only 1 coffee this morning I may just be blind. I think this is a really useful addition. bugzilla< at >apache.org 2008-09-03T22:35:21 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14306 On 04/09/2008, at 12:33 AM, Jukka Zitting wrote: It does sound like a good candidate for log4j-extras which we do plan to release. I'd support a move, the code in the servlet package looks stable and reports such as yourself showing it's usefulness will add weight to the move. cheers, Paul Paul Smith 2008-09-03T21:55:21 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14305 Hi, I found a bunch of classes in org.apache.log4j.servlet under log4j-sandbox and I'd like to use them to replace our custom Log4J configuration code in Apache Jackrabbit. Are there any plans for releasing that code in near future? Is there anything I can do to help? Alternatively, are you aware of any legal encumbrances (NOTICE file requirements, etc.) on those classes that I should be aware of if I decide to just copy them over to Jackrabbit? BR, Jukka Zitting Jukka Zitting 2008-09-03T14:33:32 http://permalink.gmane.org/gmane.comp.jakarta.log4j.devel/14304 https://issues.apache.org/bugzilla/show_bug.cgi?id=42171 --- Comment #11 from ray< at >itasoftware.com 2008-09-03 06:03:01 PST --- I pulled to code from: http://svn.apache.org/repos/asf/logging/log4j/ I now see that I should have pulled it from: http://svn.apache.org/repos/asf/logging/log4j/companions/receivers/ Looks like it's basically the same code, though, so it shouldn't be a problem to move it over once I get everything checked out properly. I'll probably have a chance sometime this week. bugzilla< at >apache.org 2008-09-03T13:03:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.jakarta.log4j.devel