Landon,
My 2c worth on this is that you should write the problem features to a
new layer. I used that approach quite a bit in JCS development, and it
worked well. With features in a layer it makes them easy to visualize,
and the user can use all the tools already in OJ to examine and/or fix
the problems.
Martin
On 9/7/2010 12:29 PM, Sunburned Surveyor wrote:
> 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<kneuf...@refractions.net>
> 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<kneuf...@refractions.net>
>>> 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
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> 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
>>> Jump-pilot-devel@lists.sourceforge.net
>>> 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
>> Jump-pilot-devel@lists.sourceforge.net
>> 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
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
------------------------------------------------------------------------------
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
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
