OK. Thanks Martin.
The only question I had about this method was the possiblity of a
"corrupt feature". It the plug-in is processing a layer with a corrupt
feature, trying to add it to another layer could throw an exception,
which is what I am trying to avoid. I suppose all the features the
plug-in is operating on could already be in an existing layer, unless
the plug-in is creating new features during a data import. That could
create a situation in which trying to report the problem with the bad
feature creates another problem when you try to add it to the layer
that stores problem features.
I'll see if there is an elegant way to handle this edge case. It won't
be an issue with the Union By Attribute plug-in, as both input layers
already exist in the project.
At any rate, when I get done with my UnionByAttribute plug-in mods,
I'll try to add a short article to the wiki so other plug-in
programmers can use the same technique to skip problem features and
write them to a new layer. I think this method of plug-in processing
makes plug-ins more robust. They also make it easier to identify
problem data. That was the whole point of my tweaking, as Nacho and I
couldn't figure out what feature in his data was causing the Union By
Attribute plug-in to choke in the first place.
The Sunburned Surveyor
On Tue, Sep 7, 2010 at 12:57 PM, Martin Davis <mbda...@refractions.net> wrote:
> 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
>
------------------------------------------------------------------------------
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
