> * Fix the logger so we can filter out messages we don't care about. Whats Freenet's take on Log4J (http://jakarta.apache.org/log4j/docs/)? It would let us dramatically simplify the management of log messages by essentially putting statements like "show DEBUG statements from freenet.node.Main" or "don't show any messages from under freenet.crypt unless they're ERROR messages" into a configuration file (.properties or .xml). You can also get incredibly useful debug information about the messages by configuring the 'layout' used by Log4J, such as the following debug line Flinks prints fires off:
480531 DEBUG BookmarkValidator.setStatus(BookmarkValidator.java:118) - 166 out of 237 completed, with 20 pending (thats the #ms since startup, the priority, the method call the log is called from, the exact location of the call, and the message). Its all configurable externally, so for optimal performance, you can just have it spit out no messages at all, or only ERROR messages without any method / location information. There is a downside to Log4J - using it in Fred may be a licensing issue, as it is released under the Apache license, not GPL. The Apache Software Foundation is of the opinion that Apache licensed software CAN be used and distributed by GPL apps (http://www.apache.org/foundation/licence-FAQ.html#GPL), but the FSF disagrees (http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses). The FSF's argument is essentially that the BSD style licenses (including Apache's) are not free because they require a line of text attributing their contribution to be added to the About box (or wherever else). Another option would be to use java.util.logging, which is very similar to Log4J (they were both based off JSR47, but java.util.logging has a lot less features). The downside of this is that it requires a 1.4 JVM. Can Fred make that requirement? In either of those cases, integration with freenet.support.Logger would be trivial - implementation and testing should take half a day or so. The third option is to build a more robust logging API manually. This would avoid the licensing issues of Log4J and the JVM issues of java.util.logging, but would require significantly more time (maybe a day or two, including testing?) Or is there another existing GPL'ed logging package others out there have had good experiences with? I've been making a lot of progress with adding JMS to Fred (the nodes can talk to each other via JMS), but it'd be really helpful to be able to filter the log messages. Thoughts? -jrandom !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ CryptoMail provides free end-to-end message encryption. http://www.cryptomail.org/ Ensure your right to privacy. Traditional email messages are not secure. They are sent as clear-text and thus are readable by anyone with the motivation to acquire a copy. !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
