[izpack-devel] Logging
Elmar Grom
elmar at grom.net
Fri Dec 1 17:21:23 CET 2006
Re: [izpack-devel] FW: LoggingHi Markus,
that's a good point. I'll change it to Throwable.
Elmar
-----Original Message-----
From: Markus Schlegel [mailto:izpack-devel-bounces at lists.berlios.de]On
Behalf Of Markus Schlegel
Sent: Thursday, November 30, 2006 11:35 PM
To: elmar at grom.net; izpack-devel at lists.berlios.de
Subject: AW: [izpack-devel] FW: Logging
Hi Elmar
Maybe you have to consider to change the "Exception" argument into
"Throwable", at least for "addError(..)".
If not, it might be nasty to log a catched java.lang.Error...
Markus
----------------------------------------------------------------------------
--
Von: izpack-devel-bounces at lists.berlios.de im Auftrag von Elmar Grom
Gesendet: Do 30.11.2006 18:20
An: izpack-devel at lists.berlios.de
Betreff: Re: [izpack-devel] FW: Logging
Hi Klaus,
here is a snippet of the API.
Log.getInstance ()
public void addMessage (int message,
String [] detail)
public void addWarning (int message,
String [] detail,
Exception exception)
public void addError (int message,
String [] detail,
Exception exception)
The integer identifiers for the messages are defined in the Log class. The
logger will pull the actual message text from the langpack when building
the
report. In this way messages are localized without extra burden on the
calling code.
In addition, the caller can provide detail information to refine the
message. To support this feature, some messages might have variable parts
defined, such as a file name, path, some numbers, settings etc. These will
be inserted by the logger from the detail array into the localized text.
For
each message it will be exactly defined if there are variable parts, what
they are and in which order the detail must be provided.
Messages are just for generic information, for example which panel was
presented or what option was chosen. Warnings and Errors are added when
things go wrong, therefore these two methods include the ability to attach
an exception. The logger will include the Exception.toString() result with
each message that had an associated exception.
It is not possible to use the identifier of an error message to add a
warning and so on, since the message identifiers are organized into groups
and each add method verifies that a legal value was used for the call
before
it actually adds the message.
I hope this answers your questions
Elmar
-----Original Message-----
From: Bartz, Klaus [mailto:Klaus.Bartz at coi.de]
Sent: Thursday, November 30, 2006 12:14 AM
To: elmar at grom.net; izpack-devel at lists.berlios.de
Subject: RE: [izpack-devel] FW: Logging
Hi Elmar,
is it possible to add an "identifier" to the message slot like
void Logger.getInstance().setMessage(String loggingSlot, String msg,
Throwable who)
or
public final static int ERROR = 0;
public final static int WARNING = 1;
public final static int MESSAGE = 2;
void Logger.getInstance().set(int type, String loggingSlot, String msg,
Throwable who)
loggingSlot and who can be null.
The dumping of slot contents for MESSAGE can be triggert by command line
(e.g. string of comma separated identifier).
In opposite to log4j (if I have understand it right) there is no hierarchy
else
special informations can be selective dumped out.
With such a mimik it is possible to log more informations without making
the
log blind bend and discussions about logged informations can be easier
blocked.
It can be simple enough to impl it self in opposite to use log4j (I do not
like
log4j :-)).
Cheers
Klaus
>-----Original Message-----
>From: izpack-devel-bounces at lists.berlios.de
>[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Elmar Grom
>Sent: Wednesday, November 29, 2006 11:37 PM
>To: Izpack
>Subject: [izpack-devel] FW: Logging
>
>
>Klaus,
>
>you make a good point here. Users might not be happy about a load of
>messages, even if they are all good.
>
>The logger works as follows:
>
>1) log messages are posted by calls to the logger
>2) there are three categories of messages: messages, warnings
>and errors
>3) the logger simply collects the messages but takes no further action
>4) the logger provides information if any warnings or errors have been
>posted
>5) the installer uses this information to display an
>appropriate generic
>message (probably in the finish panels) -> (success, possible problems,
>install failed)
>6) a button will be provided to allow the user to save a
>detailed report
>7) when asked to save a report, the logger produces a report
>with generic
>information about the install plus all messages posted. The
>messages are
>sorted by category (message/warning/error) and they are localized.
>
>In this way the user is never bombarded with a flood of
>messages that might
>only succeed in leaving doubt about the success of the operation, even
>though they might be completely meaningless. If necessary the
>report text
>file may be e-mailed to the developer.
>
>Because of your input, I think it might be a good idea to
>allow developers
>to decide if logging is actually turned on and perhaps even to
>what level.
>This could be done by a top level switch in the xml file. Even
>if this is
>done, there might be cases where an installation problem might
>need to be
>debugged. For such cases logging might be forced on by a command line
>switch.
>
>Here is what a report looks like right now. The message and
>warning section
>would not show up at all if there is nothing recorded, I just
>wanted to show
>what it would look like.
>
>---------------------------------------------------------------
>-------------
>---
> IzPack INSTALLATION REPORT
>---------------------------------------------------------------
>-------------
>---
>
>WARNING!!! The installation did not succeed!
>
>This report contains 0 general message(s), 0 warning(s) and 1 error(s)
>
>Installation report for : ProScholar Version 2.2
>Install time : 11-29-2006 [14:29:37] Pacific Standard Time
>Install directory : D:\ProgramFiles\ProScholar
>
> --- Installation Messages ---
>
>Message [0] - ...
>
> --- Warnings ---
>
>Warning [0] - ...
>
> --- Errors ---
>
>Error [0] - unable to write 'D:\ProgramFiles\ProScholar\app.jar'
>---------------------------------------------------------------
>-------------
>---
>
>
>Cheers
>
> Elmar
>
>-----Original Message-----
>From: Bartz, Klaus [mailto:Klaus.Bartz at coi.de]
>Sent: Wednesday, November 29, 2006 1:13 AM
>To: elmar at grom.net; izpack-devel at lists.berlios.de
>Subject: RE: [izpack-devel] Logging
>
>
>Hi Elmar,
>I think all developer of IzPack knows that there are some
>points in the product which are not optimal solved. Of course,
>we should solve it if possible and time is right on work-time-device.
>
>Some weeks ago I have had a little problem with logging; I log
>some things which are interested especially for me, but it will be
>logged if logging is activated. One user persisted on the
>meaning that the logged information was fatal for IzPack.
>
>Therefore it will be nice if the new logging stuff will be support
>different topics (as you have decribed) and logs a prefix. May be
>configurable what topic should be logged.
>
>Cheers
>
>Klaus
>
>_______________________________________________
>izpack-devel mailing list
>izpack-devel at lists.berlios.de
>https://lists.berlios.de/mailman/listinfo/izpack-devel
>
_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/izpack-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/izpack-devel/attachments/20061201/0f888075/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 1176 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/izpack-devel/attachments/20061201/0f888075/attachment.bin
More information about the izpack-devel
mailing list