[izpack-devel] Logging -> need feedback

Bartz, Klaus Klaus.Bartz at coi.de
Tue Dec 12 09:37:09 CET 2006

Hi Elmar,
I am waiting for it :-)
You know, I think it will be nice if there are "slots"
additional to types of events to keep track of if there are
many logs of type message. You know the situation where a 
log file containts a MB informations.
But it is only a wish of me.
Rest context related.



>-----Original Message-----
>From: izpack-devel-bounces at lists.berlios.de
>[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Elmar Grom
>Sent: Tuesday, December 12, 2006 6:27 AM
>To: Izpack
>Subject: [izpack-devel] Logging -> need feedback
>Hi everybody,
>sorry, I was spaced out for a bit, wanted to send this earlier 
>but a lot was
>going on in my world... anyway, here we continue with logging
>Please send comments, proposals etc. and let me know if you can help a
>little with this project. There is still some work to be done on many
>fronts, though none of it should be a major amount.
>What has happened and what is implemented so far?
>So far I have implemented a logger class and modified it 
>according to some
>feedback I received. This class can do the following:
>1) it can be used to log any event of interest during an installation
>2) depending on the types of events recorded 
>(message/warning/error) the
>class provides flags for the GUI to present an appropriate 
>generic message
>3) an exception can be attached to warning and error messages
>4) it can build a localized text report and provides the 
>necessary UI to
>save the report to a file of the users choice.

May be configurable. Other installer writes logging also without
asking the user. May be we can declare central a support directory
where also other loggings can be stored (e.g. the summary). 

>5) there is special handling support for use of (4) in an automated
>installer. In this case a message dialog is popped up that 
>also allows the
>user to save the report if there are any warning or error 
>messages recorded.

Have to be configurable because there are installations without
user interaction.

>What needs to be decided and what is yet to be implemented?
>1) the two finish panels need to be upgraded to display a 
>generic message
>indicating installation success
>2) the two finish panels need to be upgraded to provide a 
>button for saving
>the report

I have to see the impl or the docu to see whether I understand
the usage or not :-) If so, I can do 1) and 2).

>3) Log needs to integrated with the project (who can check the 
>code in for
>4) Julien has proposed to add a GUI element to the installer frame that
>displays a message if a warning or error was recorded. This 
>would have to be
>implemented and wired with the logger for updating.
>5) what should be done if the developer decides not to use a 
>finish panel or
>wants to write his own?

If some one will not say good by, he has bad luck. We should not
support discourteousness with a hack from us for it :-)

May be this is a good reason to bring together FinishPPanel and 
SimpleFinishPanel. At upgrading the two panels create a base class
which makes all common stuff. A developer which needs an own
finish panel should be used then this base. If not, he has also bad luck...

>6) some re-factoring work is required surrounding InstallData
>7) there are LOTS of messages to be translated ~:o)

I assume that you make the English and the German. Therefore there is
no part for me :-)

>8) logging should be used -> implement lots of logging all 
>over the code!

If system exist, I will do it in my stuff.
What about to publish the panel list where developer will be insert
his mnemonic.

>       Elmar
>izpack-devel mailing list
>izpack-devel at lists.berlios.de

More information about the izpack-devel mailing list