Bug report for Log4j [2008/08/03]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |13099|Opn|Nor|2002-09-27|DOMConfigurator ignores category factory setting | |17887|Opn|Maj|2003-03-11|RollingFileAppender does not work for 10 threads | |20395|Inf|Enh|2003-06-01|PreparedStatementAppender Enhancement | |22894|Inf|Nor|2003-09-02|Single backslash not accepted in File param value | |22934|Inf|Nor|2003-09-04|org.apache.log4j.jmx is not compatible with JMX 1.| |23329|Inf|Maj|2003-09-22|logger element in XML config should support reso| |25355|Inf|Enh|2003-12-09|allow to require TLS/SSL only for outgoing mails| |25747|New|Enh|2003-12-24|more explanations when hitting WARN No appenders | |26084|Inf|Nor|2004-01-13|Log Event detail panel does not show special chara| |27363|Inf|Enh|2004-03-02|JNI based SyslogAppender | |27367|Inf|Enh|2004-03-02|NetSendAppender | |28647|Ass|Enh|2004-04-28|Add Flush on Level capability to FileAppender | |29244|Inf|Nor|2004-05-27|Preserve XML content in log messages when using XM| |29304|New|Nor|2004-05-30|Starting XMLSocketAppender from config file | |29305|New|Nor|2004-05-30|Chainsaw doesn't see locationinfo from XMLSocketRe| |29735|New|Nor|2004-06-22|Receiver list display error when receiver has no | |30055|New|Nor|2004-07-12|Problem with registering Appenders with the same n| |30407|Inf|Maj|2004-07-30|Externally rolled file problem| |30888|New|Maj|2004-08-27|Chainsaw mixes files in same panel| |30890|New|Min|2004-08-27|Newly opened log file should get focus| |30892|New|Min|2004-08-27|Log files cannot be closed| |31089|New|Nor|2004-09-07|Does not accept ISO8601 dates in focus field | |31178|Inf|Cri|2004-09-11|Exception using Chainsaw for simple debugging | |31179|Inf|Enh|2004-09-11|Implement Chainsaw as Eclipse stand-alone applicat| |33278|New|Min|2005-01-27|NPE thrown durring daily log file rollover| |33493|Inf|Enh|2005-02-10|contribution to log4j: servlet diagnostic context | |33717|New|Nor|2005-02-23|Leaving out %throwable in ConversionPattern adds t| |34440|New|Nor|2005-04-13|sandbox:IMAppender - comma-seperated recipient lis| |34491|Ver|Nor|2005-04-18|Missing include in build.jms target results in mis| |34651|New|Enh|2005-04-27|allow for a header on top of every rolled file| |34738|New|Nor|2005-05-04|Chainsaw does not remember what Columns are select| |34945|Inf|Nor|2005-05-17|ThrowableInformation has dubious Stack Trace extra| |34974|Inf|Cri|2005-05-19|Exception when running a Pluglet | |35180|New|Min|2005-06-02|Multiple lines XML files (*.xml) in drop down li| |35239|Inf|Nor|2005-06-06|NullPointerException when saving displayed events | |35563|Inf|Enh|2005-06-30|Syslog appender parametrability | |35996|Inf|Enh|2005-08-03|Add support for ant-like property in log4j.xml | |36384|Inf|Nor|2005-08-26|Configuring triggering/rolling policies should be | |36435|New|Enh|2005-08-31|Log4J RollingFileAppender under OpenVMS does not f| |36654|Inf|Min|2005-09-14|Provide better error messages for Please initiali| |36789|Inf|Nor|2005-09-23|Empty control flow statement in org.apache.log4j.l| |36860|New|Enh|2005-09-29|[jmx] Add ability to create a logger MBean for a n| |37182|Ass|Nor|2005-10-20|Exception from exception toString() causes log4j t| |37349|Inf|Nor|2005-11-03|DBAppender not working with jTDS driver | |37638|New|Nor|2005-11-25|logging doesn't fall back with FallbackErrorHandle| |37734|Inf|Nor|2005-12-01|Customize Event ID and Event Category with NTEVent| |37762|Ass|Enh|2005-12-02|RSSAppender or other approach.| |38061|New|Nor|2005-12-28|Problem configuring an errorHandler using a proper| |38363|New|Nor|2006-01-24|SecurityException during log output | |38394|Ver|Enh|2006-01-26|PropertySetter fails to print stacktrace if error | |38395|Ver|Reg|2006-01-26|Unable to set threshold on appender via config fil|
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
Thorbjørn Ravn Andersen wrote: Ralph Goers skrev den 03-08-2008 21:45: 1.2 is the only current version. 1.3 has been discontinued. The basic work to start 2.0 has been done. A branch has been created for the initial 2.0 work at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/. Jira has been setup to capture all the work for 2.0 at https://issues.apache.org/jira/browse/LOG4J2. I am aware of that. I expect to start doing stuff in the branch within the next few weeks. Interesting. What are you planning to do and what are your goals? Take a look at the Jira issues that are already there. I imagine at first it will just be some cleanup work and going through and making Java 5 improvements. My goal is to end up with a cleaner architecture with some additional features. Unfortunately, I can't use Log4j in the application's in my environment right now because it is missing a critical feature. I will need something similar to Logback's TurboFilter before I can use it. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27367] NetSendAppender
https://issues.apache.org/bugzilla/show_bug.cgi?id=27367 --- Comment #7 from Leonardo Anceschi [EMAIL PROTECTED] 2008-08-04 04:04:02 PST --- (In reply to comment #6) I had a look at the source, and it does not use any Microsoft API but deals with a raw socket connection and byte streams. Has it been integrated in SVN yet, and where? Source code isn't in the repository. I think it could be added in the contribs directory, but I don't have the credentials. Can you help me? Leo -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LOG4J2-6) log4j 2.0 should support all capabilities of java.util.logging.
[ https://issues.apache.org/jira/browse/LOG4J2-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619570#action_12619570 ] Thorbjørn Ravn Andersen commented on LOG4J2-6: -- The java.util.logging provide the method name in the class from where it was called, which is very nice. Which other facilities are currently missing compared to log4j 1.2? log4j 2.0 should support all capabilities of java.util.logging. --- Key: LOG4J2-6 URL: https://issues.apache.org/jira/browse/LOG4J2-6 Project: Log4j 2 Issue Type: Wish Components: Core Reporter: Curt Arnold Applications that use the java.util.logging API with log4j 2.0 appenders et al should not lose any capabilities that the would have if they had used a native java.util.logging.Handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
Ralph Goers skrev den 03-08-2008 21:45: 1.2 is the only current version. 1.3 has been discontinued. The basic work to start 2.0 has been done. A branch has been created for the initial 2.0 work at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/. Jira has been setup to capture all the work for 2.0 at https://issues.apache.org/jira/browse/LOG4J2. I expect to start doing stuff in the branch within the next few weeks. I looked through the issues and there is as nothing that springs in my eye as particularily warranting a version 2 (except that to change JVM level a version number change is needed, and what benefit will changing source code to use e.g. generics bring that warrants dropping 1.2, 1.3 and 1.4 as supported platforms?). TurboFilter functionality would be nice, but should be possible to build in without dropping backwards compatability, so it could be added to 1.2 instead. I can additionally think of these things that would be nice to have: * configuration scopes - e.g. a JBoss configuration file along with a web application file mess each other up. It would be nice if they could have seperate root loggers which did not step on each others toes.This might also be able to solve the log4j cannot use log4j to log issue. * A log to console only behaviour if no configuration is active, to make the default behaviour the same as for the other logging frameworks. * Support of ZeroConf in the standard loggers (where appropriate), as network sockets are the currently best way to do inter-JVM communication which is necessary to use Chainsaw or an Eclipse plugin etc or to do centralized logging. People who have not used OS X have not seen how elegant just works can be done. The work done in chainsaw is just the beginning. * Before any work is done to improve performance, care should be taken to be able to compare before and after to see if performance actually improved. At this point in time I think it would be very beneficial to create a specification of requirements to be able to discuss what work should be done, and to determine when the next version is ready :) Otherwise it might be hard to collaborate on getting there. Just my 2 cents... -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
I believe the threading model is a big reason for moving to version 2. Please read the archives about threading/deadlock issues. Jake Thorbjørn Ravn Andersen wrote: Ralph Goers skrev den 03-08-2008 21:45: 1.2 is the only current version. 1.3 has been discontinued. The basic work to start 2.0 has been done. A branch has been created for the initial 2.0 work at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/. Jira has been setup to capture all the work for 2.0 at https://issues.apache.org/jira/browse/LOG4J2. I expect to start doing stuff in the branch within the next few weeks. I looked through the issues and there is as nothing that springs in my eye as particularily warranting a version 2 (except that to change JVM level a version number change is needed, and what benefit will changing source code to use e.g. generics bring that warrants dropping 1.2, 1.3 and 1.4 as supported platforms?). TurboFilter functionality would be nice, but should be possible to build in without dropping backwards compatability, so it could be added to 1.2 instead. I can additionally think of these things that would be nice to have: * configuration scopes - e.g. a JBoss configuration file along with a web application file mess each other up. It would be nice if they could have seperate root loggers which did not step on each others toes.This might also be able to solve the log4j cannot use log4j to log issue. * A log to console only behaviour if no configuration is active, to make the default behaviour the same as for the other logging frameworks. * Support of ZeroConf in the standard loggers (where appropriate), as network sockets are the currently best way to do inter-JVM communication which is necessary to use Chainsaw or an Eclipse plugin etc or to do centralized logging. People who have not used OS X have not seen how elegant just works can be done. The work done in chainsaw is just the beginning. * Before any work is done to improve performance, care should be taken to be able to compare before and after to see if performance actually improved. At this point in time I think it would be very beneficial to create a specification of requirements to be able to discuss what work should be done, and to determine when the next version is ready :) Otherwise it might be hard to collaborate on getting there. Just my 2 cents... -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: plain log4j trunk - mvn install fails
I have had no problems mvn installing log4j (I've needed to do so a lot because Pinpoint and some other log4j-* projects link against the current SNAPSHOT). mvn dependency:tree will show you all the dependencies and transitive dependencies. Paul On 04/08/2008, at 7:00 AM, Thorbjørn Ravn Andersen wrote: Hi. I am trying to figure out how to build the various subprojects of log4j, and just want to know if it is just my configuration or if Oro is required to run mvn install in log4j trunk? (I also disabled the NTEventAppenderTest in test/build.xml as this is under XP). Is log4j being built by Gump? -- Thorbjørn Ravn Andersen ... plus... Tubular Bells! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Paul Smith Core Engineering Manager Aconex The easy way to save time and money on your project 696 Bourke Street, Melbourne, VIC 3000, Australia Tel: +61 3 9240 0200 Fax: +61 3 9240 0299 Email: [EMAIL PROTECTED] www.aconex.com This email and any attachments are intended solely for the addressee. The contents may be privileged, confidential and/or subject to copyright or other applicable law. No confidentiality or privilege is lost by an erroneous transmission. If you have received this e-mail in error, please let us know by reply e-mail and delete or destroy this mail and all copies. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. The sender takes no responsibility for the effect of this message upon the recipient's computer system.
DO NOT REPLY [Bug 41006] Contributing XMLSocketHubReceiver
https://issues.apache.org/bugzilla/show_bug.cgi?id=41006 --- Comment #4 from Paul Smith [EMAIL PROTECTED] 2008-08-04 14:29:25 PST --- Yeah, it's destined for log4j-receivers once reviewed. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
Thorbjørn Ravn Andersen wrote: Ralph Goers skrev den 03-08-2008 21:45: 1.2 is the only current version. 1.3 has been discontinued. The basic work to start 2.0 has been done. A branch has been created for the initial 2.0 work at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/. Jira has been setup to capture all the work for 2.0 at https://issues.apache.org/jira/browse/LOG4J2. I expect to start doing stuff in the branch within the next few weeks. I looked through the issues and there is as nothing that springs in my eye as particularily warranting a version 2 (except that to change JVM level a version number change is needed, and what benefit will changing source code to use e.g. generics bring that warrants dropping 1.2, 1.3 and 1.4 as supported platforms?). TurboFilter functionality would be nice, but should be possible to build in without dropping backwards compatability, so it could be added to 1.2 instead. I don't think you looked carefully enough. Fixing some of the way things are currently implemented will probably break compatibility. For example, getting rid of Category - which has been deprecated for years. Creating a good implementation of LocationInfo requires Java 5 as that is when Thread.getStackTrace() became available. nio didn't become available until 1.4. Frankly, I have zero interest in working on a log4j that doesn't have Java 5 as a minimum. Log4j is good enough for older Java releases but real improvements need to be made. I can additionally think of these things that would be nice to have: * configuration scopes - e.g. a JBoss configuration file along with a web application file mess each other up. It would be nice if they could have seperate root loggers which did not step on each others toes.This might also be able to solve the log4j cannot use log4j to log issue. One way or another, JBoss and log4j need to play better together. I created https://issues.apache.org/jira/browse/LOG4J2-18 just for that. Feel free to update it with your thoughts. * A log to console only behaviour if no configuration is active, to make the default behaviour the same as for the other logging frameworks. Agree. * Support of ZeroConf in the standard loggers (where appropriate), as network sockets are the currently best way to do inter-JVM communication which is necessary to use Chainsaw or an Eclipse plugin etc or to do centralized logging. People who have not used OS X have not seen how elegant just works can be done. The work done in chainsaw is just the beginning. * Before any work is done to improve performance, care should be taken to be able to compare before and after to see if performance actually improved. Yes - it is very important to have tests to continually measure that. I already have one that I use. At this point in time I think it would be very beneficial to create a specification of requirements to be able to discuss what work should be done, and to determine when the next version is ready :) Otherwise it might be hard to collaborate on getting there. Just my 2 cents... The point of the Jira issues was to do exactly that. I suggest that instead of posting the ideas here where they will probably be forgotten that you add them as Jira issues. Then go ahead and start figuring out how to implement them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
Jacob Kjome wrote: I believe the threading model is a big reason for moving to version 2. Please read the archives about threading/deadlock issues. Jake Did that get covered by any of the Jira issues? If not (and I don't think so), please add it. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
