Kevin, Thanks for the clarification. I agree that since the project is already has Log4J as a dependency, we should use it to replace the System.out statements in the core.
I was thinking about plug-in developers as well. I'm working on the Union By Attribute plug-in. I'm tweaking it to report and skip problem features during execution. I had originally thought about writing the problem features to a new layer, but another reasonable solution would be to write the WKT for the feature with some type of error message to a log file. I thought it would be good to have all plug-ins report problems of this type to the same log file, possibly using a class accessed through the plug-in context. We might have a PlugInReporter class with methods like reportPlugInExecutionProblem(String errorMessage) or reportProblemData(List<Feature> problemFeatures). I thought the implementation of this class might use Log4J in the way you describe. I'm just thinking out loud. I need to consider the problem more carefully before I come up with a solution. I will keep Log4J in mind when I work on the logging implementation. In the meantime, I'll add replacing those 300+ System.out calls with a Log4J technique to my to do list. I've printed out an article on Log4J so I can learn some more about how it works. The Sunburned Surveyor On Tue, Sep 7, 2010 at 11:14 AM, Kevin Neufeld <[email protected]> wrote: > Hi Landon, > > I'm not sure I understand your question, sorry. I'm not suggesting to > expose any method to access logging functionality. > > I hope this makes this more clear: > What I'm suggesting is that the 330 calls to System.out currently in src > get cleaned up, replaced with appropriate log4j calls. > > ie. > System.out.println("Starting OpenJUMP"); > logger.info("Starting OpenJUMP"); > > System.out.println("Entering my private method"); > logger.debug("Entering my private method"); > > System.out.println("Should never reach here !!!"); > logger.fatal("Should never reach here !!!", exception); > > > Log4j then needs a configuration defined so it knows where to output the > log statements, if at all. This can be done from an xml file specified > from the JVM (which is what is currently done): > > -Dlog4j.configuration=file:etc/log4j.xml > > > or from an xml file specified as a application argument: > > import com.foo.Bar; > > import org.apache.log4j.Logger; > import org.apache.log4j.DOMConfigurator; > > public class MyApp { > > static Logger logger = Logger.getLogger(MyApp.class); > > public static void main(String[] args) { > > // Configure using log4j.xml file > DOMConfigurator.configure(args[0]); > > logger.info("Entering application."); > Bar bar = new Bar(); > bar.doIt(); > logger.info("Exiting application."); > } > } > > > or programmatically, hard-coded: > > > import com.foo.Bar; > > import org.apache.log4j.Logger; > import org.apache.log4j.BasicConfigurator; > > public class MyApp { > > static Logger logger = Logger.getLogger(MyApp.class); > > public static void main(String[] args) { > > // Set up a simple configuration that logs on the console. > // (not that OJ would do this) > BasicConfigurator.configure(); > > logger.info("Entering application."); > Bar bar = new Bar(); > bar.doIt(); > logger.info("Exiting application."); > } > } > > > A possibility exists that OJ could accept a log_level parameter. If not > specified, the default log4j.xml file could be used outputting "info" > and above statements to a log file. If specified, a different log4j.xml > file or hard-coded root logger could be used to output trace/debug log > statements and above to a log file. This could be useful for bug > reporting. As a plugin developer, I can specify my own configuration > file that ignores all log statements except those in my own java > package, writing them to my console. > > I know OJ currently uses log4j. If the OJ team wants to fully go the > log4j route, then all I'm suggesting for now is that the 330 output > statements get cleaned up. > > But, Landon, I think you made an excellent point earlier ... some of > these statements should also be reported to the user > (https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Displaying_Debug_Messages) > in addition to being logged. > > > Cheers, > Kevin > > > On 9/7/2010 8:43 AM, Sunburned Surveyor wrote: >> I'll have to take a look at log4J again. Did you imagine exposing a >> method to access the logging functionality through the plug-in >> context, or through some other mechanism? >> >> The Sunburned Surveyor >> >> On Tue, Sep 7, 2010 at 8:29 AM, Kevin Neufeld<[email protected]> >> wrote: >>> On 9/7/2010 7:38 AM, Sunburned Surveyor wrote: >>>> Stefan, >>>> >>>> ... I have used Log4j before, >>>> and it seemed a little complicated. >>> I find the log4j.properties variant complicated as well. But the >>> log4j.xml [1] configuration variant I find fairly straight forward [2]. >>> I can include/exclude log messages from particular java packages and log >>> priorities. >>> >>>> I wonder if just having the >>>> ability to write messages to a simple plain-text log file would >>>> suffice. >>>> >>> Which is one of many output appenders available to log4j :) I agree, >>> this is what I would recommend. From user's perspective, one can submit >>> the log file when posting a bug report. We can even include a parameter >>> in the JUMP launcher that would temporarily set the log priority to >>> debug or even verbose to help with bug reports. >>> >>> My 2 cents, >>> -- Kevin >>> >>> >>> [1] http://wiki.apache.org/logging-log4j/Log4jXmlFormat >>> [2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat#Example_2 >>> >>> ------------------------------------------------------------------------------ >>> This SF.net Dev2Dev email is sponsored by: >>> >>> Show off your parallel programming skills. >>> Enter the Intel(R) Threading Challenge 2010. >>> http://p.sf.net/sfu/intel-thread-sfd >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> Jump-pilot-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Jump-pilot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
