Opened 20 years ago
Closed 17 years ago
#709 closed defect (fixed)
Enable use of LOG directive in MapScript
Reported by: | dmorissette | Owned by: | dmorissette |
---|---|---|---|
Priority: | high | Milestone: | 5.0 release |
Component: | MapServer C Library | Version: | 4.3 |
Severity: | normal | Keywords: | |
Cc: | mapserver@… |
Description (last modified by )
In the current version of MapServer, the LOG directive is handled only inside the mapserv CGI and has no effect in MapScript. We have lots of code generating msDebug() output to stderr when debug is enabled, but that requires a debug build and is a pain to use in some circumstances.
I would like to change things so that msDebug() output is set to the file specified by WEB/LOG if it is set, and to stderr if WEB/LOG is not set. Plus all msSetError() calls should be logged to that same logfile in MapScript just like with the mapserv CGI.
Any comments/objections before I make that change? (Other than saying that we should have done that a few years ago!)
Change History (15)
comment:3 by , 20 years ago
Um... I just read a note about MS_ERRORFILE on the list which reminded me why I had not fixed this logging issue initially when I wrote msDebug(). I had forgotten about that one: > The other is to set an envionment variable MS_ERRORFILE to some file name > -- then look at it -- this should work in any enviromnent -- the docs say > that you can (in 4.2) put a "CONFIG MS_ERRORFILE fn.log" in the MAP file but > I have not been able to verify this yet. Looking at the code, I realize that the intention behind the WEB/LOG directive was to log mapserv requests and fatal errors if applicable. OTOH the MS_ERRORFILE logs all calls to msSetError(). So I guess if I don't want to break this design I should have msDebug() write to the MS_ERRORFILE and recommend to users to set "CONFIG MS_ERRORFILE fn.log" ... even though it would sound more intuitive to set WEB/LOG from the user's point of view. What do we want to do? Do we want to direct all logging to the WEB/LOG file (MS_ERRORFILE would become an alias for WEB/LOG) or keep things separate as they are today, in which case where should msDebug() output go?
comment:4 by , 20 years ago
Milestone: | → 4.4 release |
---|
comment:5 by , 20 years ago
Cc: | added |
---|
comment:6 by , 20 years ago
Owner: | changed from | to
---|
On mapserver-dev, Frank Warmerdam wrote: > Folks, > > Quite a few times I have found that errors are being issued with > msSetError(), but never get displayed to the user (or developer) because > nothing "up the stack" is looking for it. > > We have a mechanism to see all errors issued via msSetError() by setting > the MS_ERRORFILE environment variable. I for one essentially never have > this > set, partly because it is a nuisance to set from within GDB (as set > environment > does not seem to really affect the process that is run). I have made a > small > change so that a line of the form 'CONFIG MS_ERRORFILE "stderr"' will > result > in a putenv() call within the process. This means that error reporting can > be enabled within a mapfile (though in fact the value will stick outside > the > narrow context of the map). I have also changed it so that -all_debug on > the commandline for shp2img will always set MS_ERRORFILE=stderr. > > However, I am wondering if we can go a bit further, and have turning on map > level debugging always set MS_ERRORFILE=stderr *if* MS_ERRORFILE isn't already > set. This would mean, in my mind, that turning on the MAP DEBUG statement would > help get alot more sigificant debug info into the log. > > Any objections? Questions? Suggestions? > Frank, I like the idea, and would also suggest adding a -all_debug option to the mapserv CGI since this is what I use for debugging most of the time instead of shp2img. Actually, I had already opened bug 709 to try to solve this issue so I think we should move the discussion there: http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=709 The title of the bug was to enable the LOG directive in MapScript, but my goal was really to expose the errors and debugging information more easily to the users, so your suggestion would be an appropriate fix. ---- Reassigned bug to Frank.
comment:9 by , 18 years ago
blocked: | → 1333 |
---|
comment:10 by , 18 years ago
blocked: | → 1783 |
---|
comment:12 by , 18 years ago
Cc: | removed |
---|
comment:13 by , 18 years ago
Cc: | removed |
---|
comment:14 by , 17 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
MS RFC 28 proposes a solution to this ticket:
comment:15 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The implementation of MS-RFC-28 in r6271 solves this by merging the DEBUG and MS_ERRORFILE mechanisms into a single one, allowing more control out the location of the output (via MS_ERRORFILE) and more debug levels. See the RFC for full details.