Re: Chainsaw harmonization, branding, etc.
I used the assembly:assembly plug to create a distribution, however the descriptor (src/assembly/bin.xml) needs to be tweaked to drop out non-re-distributable jars. Hopefully, all the non-re- distributable jars are not essential to operation, at least not on JDK 1.5. Currently, you can do java -jar on apache-chainsaw.jar and the app launches. I added the main-class and path entries to the chainsaw jar, wouldn't do that on a library jar but hopefully is a good thing for an application jar. I've never found that main-class much use because of the external reference to jars. Personally I like the appassembler distribution that maven can build, plus the Mac-specific one. The external referenced jars are the crux of the problem with Chainsaw. Out-of-the-box, Chainsaw is useful for socket-based operations and local file reading. For JMS, DB, and VFS style operations, the 3rd-party requirements make it a tricky distribution problem. Which exactly are the non-redistributable jars? Xstream and jmdns are the only listed dependencies in the pom, both of which are ASL licensed. JSch (for ssh-based stuff like vfs) used to LGPL but is now BSD licensed, but we don't actually need to depend on that per-se (they can go in the plugins directory). I will probably need to get my head around the distribution mechanisms. I think we do need a classic distribution tarball that is farmed out to the distribution mirrors. Keeping the WebStart is good, but I think it might need to be placed within and use the Maven repo and have the downloads page point to a nearby Maven mirror. We might as well be consistent with a tarball distro, but I'm not sure that's what the users would want to use. For non-webstart operations I actually think letting the user use Maven to build the complete distribution including all dependencies is actually probably the most pain-free for a user. Branding is another issue. Should Chainsaw be presented as a separate product or as a log4j companion or some other model. I've probably not been consistent in what I've set up, but here is how I see the options: Chainsaw as a LS product: Web content: http://logging.apache.org/chainsaw, appear as menu item on http://logging.apache.org groupId = apache-chainsaw or log4j artifactId = apache-chainsaw Chainsaw as a log4j companion: Web content: http://logging.apache.org/log4j/companions/chainsaw, appear as menu item on http://logging.apache.org/log4j and http:// logging.apache.org/log4j/1.2 groupId = log4j artifactId = apache-log4j-chainsaw I think that LS product is better since Chainsaw should be usable with the other LS frameworks and is much more complicated than the other companions. Also, the plugin components could be considered "companions" of chainsaw. Given Chainsaw can interact with non-log4j environments as well with XML logging, I think a standalone position is probably more appropriate. I don't have a problem having Chainsaw continue to use the log4j icon, but maybe we could create a derivative icon that suggest taking a slice of the log4j cup. Don't know if we have access to the original drawing for the icon. Scott and I talked about this a while back, but neither of us a gFx artists.. :) I had always envisaged an image that was a piece of paper with text and a chainsaw slicing right through it. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw TODO's
On 30/06/2007, at 7:15 AM, Curt Arnold wrote: There is a splash screen that shows Chainsaw history. That should be integrated into src/changes/changes.xml. Is this is the Release Notes section you're referring to? Yes I think tracking the changes in changes.xml is probably best from now on. If there's a way to generate from this an html file that is 'injected' into the generate-sources phase of maven, then Chainsaw can ship with a HTML copy of that file. I placed an empty development roadmap in src/site/apt/roadmap.apt. thanks. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw harmonization, branding, etc.
On Jul 1, 2007, at 5:27 PM, Paul Smith wrote: I used the assembly:assembly plug to create a distribution, however the descriptor (src/assembly/bin.xml) needs to be tweaked to drop out non-re-distributable jars. Hopefully, all the non-re- distributable jars are not essential to operation, at least not on JDK 1.5. Currently, you can do java -jar on apache-chainsaw.jar and the app launches. I added the main-class and path entries to the chainsaw jar, wouldn't do that on a library jar but hopefully is a good thing for an application jar. I've never found that main-class much use because of the external reference to jars. The combo of Main-Class and Class-Path in there currently does allow the jar to be double-clicked and successfully launch after the tarball is expanded. It does seem desirable in addition to the others. Personally I like the appassembler distribution that maven can build, plus the Mac-specific one. The external referenced jars are the crux of the problem with Chainsaw. Out-of-the-box, Chainsaw is useful for socket-based operations and local file reading. For JMS, DB, and VFS style operations, the 3rd-party requirements make it a tricky distribution problem. Which exactly are the non-redistributable jars? Xstream and jmdns are the only listed dependencies in the pom, both of which are ASL licensed. JSch (for ssh-based stuff like vfs) used to LGPL but is now BSD licensed, but we don't actually need to depend on that per- se (they can go in the plugins directory). I don't think we can redistribute activation.jar, jms-1.1.jar, jmxri-1.2.1.jar, jmxtools-1.2.1.jar and mail-1.4.jar which are currently included in the generated tarball and zip archive. They are in the assembly since they are referenced by log4j, but they can be suppressed. I will probably need to get my head around the distribution mechanisms. I think we do need a classic distribution tarball that is farmed out to the distribution mirrors. Keeping the WebStart is good, but I think it might need to be placed within and use the Maven repo and have the downloads page point to a nearby Maven mirror. We might as well be consistent with a tarball distro, but I'm not sure that's what the users would want to use. For non-webstart operations I actually think letting the user use Maven to build the complete distribution including all dependencies is actually probably the most pain-free for a user. That would require Maven and a JDK where the current tarball can be launched with just a JRE and tar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw TODO's
On Jul 1, 2007, at 5:29 PM, Paul Smith wrote: On 30/06/2007, at 7:15 AM, Curt Arnold wrote: There is a splash screen that shows Chainsaw history. That should be integrated into src/changes/changes.xml. Is this is the Release Notes section you're referring to? Yes I think tracking the changes in changes.xml is probably best from now on. If there's a way to generate from this an html file that is 'injected' into the generate-sources phase of maven, then Chainsaw can ship with a HTML copy of that file. Yes. I think it could be generated and placed in the assembled jar. I'm not sure if generate-sources is the best phase, but that could be worked out. Also the Help/About should say that the product is brought to you by the Apache Software Foundation or the Apache Logging Services Project instead of the Log4j team. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j 1.2.15 and companion release candidates
On Jun 28, 2007, at 1:03 AM, Scott Deboy wrote: I pulled everything about 2 weeks ago and ran everything through Chainsaw. The backported receivers which set properties on events (all of the new network appenders) are throwing NPEs - around the property setting code if I recall. We should do something about that - by either supporting properties or preventing the NPEs. Any chance you could recreate the test and provide stack traces or a description on how to reproduce the observed problem? Pretty much stalled on addressing it until then. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chainsaw harmonization, branding, etc.
I don't think we can redistribute activation.jar, jms-1.1.jar, jmxri-1.2.1.jar, jmxtools-1.2.1.jar and mail-1.4.jar which are currently included in the generated tarball and zip archive. They are in the assembly since they are referenced by log4j, but they can be suppressed. None of those should be shipped anyway. Chainsaw either does not use them, or need to be placed in the plugins directory alongside the driver-specific jar (in the case of the jms one). We'd also want to specifically exclude the VFS, DB and JMS Receivers from the distribution for the same reason, hence the need for some customized Receiver distribution for Chainsaw only. We might as well be consistent with a tarball distro, but I'm not sure that's what the users would want to use. For non-webstart operations I actually think letting the user use Maven to build the complete distribution including all dependencies is actually probably the most pain-free for a user. That would require Maven and a JDK where the current tarball can be launched with just a JRE and tar. yes true. I was originally thinking that there was more jars that need to be distributed than can normally be with an Apache distribution (LGPL etc). Given that the VFS and jmdns bits and bobs are now ASL compatible I think that has been removed. Now the Webstart and tarball distribution can contain the exactly the same elements. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Log4j [2007/07/01]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 569|Ver|Cri|2001-02-09|fully qualified class name used as category name c| |13099|Opn|Nor|2002-09-27|DOMConfigurator ignores category factory setting | |14350|New|Enh|2002-11-07|Patch to substitute variables in the log4j.configu| |15585|Ver|Maj|2002-12-20|log4j does not show Class Name, Method, or Line Nu| |16280|Opn|Min|2003-01-21|Error Message always logged to log4j when calling | |17498|New|Nor|2003-02-27|Logging inconsistencies using DailyRollingFileAppe| |17531|Ass|Min|2003-02-28|PropertyConfigurator.configureAndWatch() don't res| |17887|Opn|Maj|2003-03-11|RollingFileAppender does not work for 10 threads | |20395|New|Enh|2003-06-01|PreparedStatementAppender Enhancement | |22894|Opn|Nor|2003-09-02|Single backslash not accepted in File param value | |22934|Opn|Nor|2003-09-04|org.apache.log4j.jmx is not compatible with JMX 1.| |23329|Ass|Maj|2003-09-22| element in XML config should support reso| |25106|Opn|Enh|2003-12-01|Support XInclude in XML configuration scripts | |25107|New|Enh|2003-12-01|OptionConverter.getSystemProperty() does not allow| |25355|New|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|New|Nor|2004-01-13|Log Event detail panel does not show special chara| |26345|New|Nor|2004-01-22|Loader always uses ContextClassLoader for getting | |27363|New|Enh|2004-03-02|JNI based SyslogAppender | |27367|New|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| |29574|New|Enh|2004-06-15|Contribution: Simple Generic MDC filter | |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|Opn|Maj|2004-07-30|Externally rolled file problem| |30564|New|Nor|2004-08-10|log4j CVS compile error vs. VFS CVS. | |30709|New|Nor|2004-08-17|Manual uses deprecated DOMConfigurator| |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 | |31155|Ass|Enh|2004-09-09|Refactor resource bundle access | |31178|Opn|Cri|2004-09-11|Exception using Chainsaw for simple debugging | |31179|New|Enh|2004-09-11|Implement Chainsaw as Eclipse stand-alone applicat| |31458|New|Nor|2004-09-28|DailyRollingFileAppender fails with mult load-bala| |31727|New|Maj|2004-10-15|Level WARN and INFO from a logfile will be recogni| |32527|New|Nor|2004-12-04|log4j initialization in java1.3 no dom in class pa| |32572|New|Enh|2004-12-07|Would like to use Filter's as TriggeringEventEvalu| |32752|New|Maj|2004-12-17|MDC.put and MDC.get signatures changed between 1.2| |32810|New|Enh|2004-12-22|Localization of logging messages | |32906|Inf|Nor|2004-12-31|Logging to Console stops working when context rest| |33278|New|Min|2005-01-27|NPE thrown durring daily log file rollover| |33493|New|Enh|2005-02-10|contribution to log4j: servlet diagnostic context | |33502|New|Nor|2005-02-10|DOMConfigurator.configureAndWatch does not perform| |33717|New|Nor|2005-02-23|Leaving out %throwable in ConversionPattern adds t| |34223|New|Enh|2005-03-29|Appender specific ObjectRenderer | |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|
