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-tabpanel&focusedCommentId=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]
Re: DO NOT REPLY [Bug 43204] Contribution Java 5+ Improvements: String formatter, stack trace inspection
Ralph Goers skrev den 05-08-2008 03:42: 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. That is true. So 100% binary compatability will not be kept. 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'm looking forward to seeing what you specifically have in mind. There are probably a lot of things I have missed living firmly in the pre-1.5 world (we have to be able to run on plain AS/400 installations where 1.3 is the only JVM available). 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. I'll have a look at it 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. I know. Perhaps it is just a matter of habit, but I like to discuss things before creating the issues. -- Thorbjørn Ravn Andersen "... plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
