Feature Requests item #1521473, was opened at 2006-07-12 14:26 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379136&aid=1521473&group_id=23629
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Egon Willighagen (egonw) Assigned to: Nobody/Anonymous (nobody) Summary: Better STDOUT/STDERR support Initial Comment: At this moment STDOUT and STDERR are used to get messages into the JmolConsole, making it rather difficult to catch and redirect these somewhere other than this JmolConsole. For example, Bioclipse has it's own console, but some Jmol messages are debug or error messages, while others are really informative messages for the user. Moreover, I can't just route STDOUT to the BioclipseConsole anyway, as any Bioclipse plugin could potentially spit things to STDOUT... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-13 00:16 Message: Logged In: NO Nico, sounds reasonable. ---------------------------------------------------------------------- Comment By: Nicolas (nicove) Date: 2006-07-12 23:03 Message: Logged In: YES user_id=1096197 My 2 cts: - create an Interface (LoggerInterface) with methods: debug(), info(), warn(), error(), fatal() (the usual levels for example in Log4j) - create a Class (DefaultLogger) implementing the above interface which would simply output messages to stdout or stderr depending on the level - create a Class (Logger ?) with static methods debug(), ... to do the output by calling the above class, and also static methods to change the class really used for the output. - replace all the print() calls by Logger.debug(), Logger.info(), ... Note: Put all the classes / interfaces above in a separate package This would be very adaptable: - for example, Bioclipse could code it's own class implementing LoggerInterface and use it instead of Jmol default one. - if Jmol is integrated in an other project, they could for example use Log4J ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-12 22:20 Message: Logged In: NO Ok, the systemOutPrintln() is probably a first good step; splitting them up according to some verbosity level would be good too. Except for the verbosity level, I would like to request the option to be able to set the PrintStream to where the "sysout"s go. ---------------------------------------------------------------------- Comment By: Bob Hanson (hansonr) Date: 2006-07-12 22:12 Message: Logged In: YES user_id=1082841 There isn't an actual request here, but I did some testing, and I have this to report: There are 412 instances of "System.out.println" in the Viewer package. Some of these might be commented out; it's not a perfect count. I changed these to "viewer.systemOutPrintln" calls, and then added a flag that turns these off. "set systemOutEnabled false" and back on "set systemOutEnabled true". Interestingly enough, there was also an unused nonpublic "logError()" function that did exactly this, but was never implemented. So basically I have replaced "viewer.logError()" with "viewer.systemOutPrintln()". I realize that that is only the first step - the second would be to go through these and decide which should go to the equivalent of STDOUT and which to the equivalent of STDERR -- and which should just be abandoned. But the point is, it's pretty easy to do this sort of wholesale change. Should I commit these changes? Are we OK with that? It obviously doesn't affect any functionality (well, it COULD, but I think we've been careful not to load any actual functionality into any System.out.println() call. So I think the chances are very good that it is not a problem. The changes are all minor, but they are all over the place (about 70 files, I think). And the changes I put in really make it SILENT when you flip that toggle. We could have something like verbose levels if we wanted. You decide. What's the actual feature request? Bob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=379136&aid=1521473&group_id=23629 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
