[Mapbender-dev] State of Logging, Exceptions

Tue Feb 16 03:38:10 EST 2010

Hi there,

this is a suggestion I welcome very much. Thanks for taking the 
initiative on this one.

We have to discuss how we can migrate from the existing solution to the 
new one.

If your code doesn't affect any existing behaviour, you could add it to 
trunk right away.

Christoph

Astrid Emde schrieb:
> Hello Karim,
>
> thanks for your input.
>
> Your suggestion sounds quite sympathic to me.
>
> Maybe we wait till Christoph is back and discuss it with him.
>
> If we want to implement it, it may make sense to take it to the next
> version (2.8) and not to 2.7. Or will it be ok for 2.7?
>
> You could make a ticket in trac for this change.
>
> Best regards astrid
>
>
>
> On Mon, February 8, 2010 5:54 pm, Karim Malhas wrote:
>   
>> Dear All,
>>
>>
>> I recently looked into what Mapbender offers as it's logging options,
>> and I found this : //if you are familiar with the logging code, skip down
>> to "While this works";
>>
>> Clientside:
>>
>>
>> classes in lib/exception.js: Mapbender.Exception, Mapbender.Warning,
>> Mapbender.Notice
>> all derived from the class Mb_log
>>
>> usage:
>> new Mapbender.Exception("exeption message goes here");
>>
>> The different classes differ internally in that they call
>> Mb_log.throwException(message,level) with different levels
>> this function in return checks if the loglevel is defined somewhere
>> globally, and then depending on the value of another global variable,
>> either posts the stuff to the server, issues a console.log, or simply
>> alerts.
>>
>> If the logmessage reaches the serverside, they are translated into
>> an approximate serverside log-equivalent (php/mb_js_exception.php)
>>
>>
>> Serverside
>>
>>
>> classes:
>> mb_exception, mb_warning, mb_notice all derived from mb_log (which is an
>> abstract class)
>>
>> usage:
>> $e = new mb_exception("exception message goes here");
>> $e = new mb_warning("warning message goes here");
>>
>>
>> The same way as the javascript logging classes, the difference between
>> these different classes, ist just that they internally set a different
>> string and pass it to the mb_log method they inherted from mb_log (the
>> class) The messages end up in the "log/" directory of the Mapbender
>> installation.
>>
>>
>>
>>
>>
>> While this works, to me this is not an ideal situation.
>>
>>
>> - The code mixes the concepts of Logging and Exceptions:
>> When I think of Exceptions, I think of objects that can be thrown and
>> caught, and when neccesary, logged to the DEBUG (or some other) level. But
>> not every Exceptions needs to generate a log entry, rather, it should be
>> dealt with, bubbled up, and only if all else fails should the user (via
>> some kind of notification) or the developer (via the log) be informed of a
>> problem.
>>
>> - All logs go to a file, or configurable from core/system.php to FireBug
>> There's no flexible way to change the location of the logfile (one has
>> to change php/classes_mb_log.php). There's also no way to log to syslog,
>> for example
>>
>>
>> So I propose we change it :-) maybe not right now, but we could keep it
>> in mind.
>>
>> I am thinking something along the lines of the following:
>>
>>
>> Clientside:
>>
>>
>> var log = new Logger("mapbender_installation_5);
>>
>> var alertHandler = new AlertHandler(); log.addHandler(alertHandler);
>>
>> var serverHandler = new ServerHandler("log.php");
>> log.addHandler(serverHandler);
>>
>>
>> log.notice("mapbender is starting up"); ...
>> log.debug("loaded 24 elements"); try{ ...
>> }catch(E){
>> if (E instanceOf TypeError){ // tell user to enter better data
>> return; }
>>
>>
>> // all else failed
>> log.debug("caught Exception in the_method(): "+ E); // tell user that
>> evreything went horribly wrong and they should // try turning it off and
>> on again }
>>
>>
>> (and something similar for serverside php)
>>
>>
>>
>> So there are two components to generating the log message:
>>
>>
>> - a Logger class that takes care about which loglevels to provide, and
>> which loglevels to log
>>
>> - a logHandler class that actually formats and writes a logmessage.
>> On the client side, the message could go into an alert, the console,
>> written onto the page itself, displayed in a jquery dialog, set to the
>> server, etc On the Server side the message could go into the normal
>> mapbender log, to syslog, Firebug, the Windows eventlog, and wherever else
>> you could want it.
>>
>> I am especially after being able taking advantage of syslog.
>>
>>
>>
>> I actually have a (mostly complete) implementation of the above, and I
>> was wondering if anyone else is interested in having this integrated.
>>
>> Maybe it's not the right time, with a release coming up, but it has
>> bothered me a bit for a while.
>>
>>
>> Regards,
>> Karim
>>
>>
>> _______________________________________________
>> Mapbender_dev mailing list
>> Mapbender_dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapbender_dev
>>
>>
>>     
>
>
>   

-- 

********************************************
FOSSGIS Konferenz 2010
2. - 5. März 2010 in Osnabrück
http://www.fossgis.de/konferenz
********************************************

----------------------------------

Aufwind durch Wissen!

Qualifizierte OpenSource-Schulungen
bei der www.foss-academy.eu

---------------------------------- 

_______________________________________

W h e r e G r o u p GmbH & Co. KG

Siemensstraße 8
53121 Bonn
Germany

Christoph Baudson
Anwendungsentwickler

Fon: +49 (0)228 / 90 90 38 - 15
Fax: +49 (0)228 / 90 90 38 - 11
christoph.baudson at wheregroup.com
www.wheregroup.com
Amtsgericht Bonn, HRA 6788
_______________________________________

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:
Olaf Knopp, Peter Stamm
_______________________________________ 