Thanks for the feedback Michael. Landon
2010/9/7 Michaël Michaud <[email protected]>: > Hi, > > Of course, I agree with Martin's solution to report bad features in a > dedicated layer. > > Ede also reminded us about the HTMLFrame, which may not be well suited > to report geometry problems, but which is the way to go for other > information messages directed to the user (ex. statistics, explanations > about the problem encountered, advice to solve it...). The use of > HTMLFrame looks like the use of logging, except messages in HTMLFrame > are directed to the user, and logging messages are directed to developpers. > > I understand also your concern about degenerated geometries as I tried > to solve such a case during the reading of degenerated shapefiles (I did > not choose to create a new layer for that, but it could have been a good > solution). To be able to report geometries which are 1) readable by > OpenJUMP and 2) similar to the original geometry, I choosed to change > the geometry type (ex. a degenerated polygon with less than 4 points can > be shown as a linestring without loosing much information) > > my 2 cents > > Michaël > > > > Le 07/09/2010 22:00, Sunburned Surveyor a écrit : >> 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<[email protected]> >> 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<[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 >>>> >>> -- >>> 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 >>> [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 > ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
