[izpack-devel] Starting a discussion about logging

[Bartz, Klaus]

Hi,
I vote first for java.util.logging, second an in-house solution 
and last log4j.
Comments context related.

Cheers 

Klaus

>-----Original Message-----
>From: izpack-devel-bounces at lists.berlios.de
>[mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Eric Rose
>Sent: Monday, August 28, 2006 12:24 AM
>To: izpack-devel at lists.berlios.de
>Subject: Re: [izpack-devel] Starting a discussion about logging
>
>
>On Monday 28 August 2006 05:36, Marc Eppelmann wrote:
>> Hi all,
>>
>> Since it was several wished, that IzPack *always* logs its 
>steps and files
>> that are written, substituted and executed to a _user-defined_ or
>> timestamp-based logfile, I re-invoke this discussion.
>
>Good - that's one thing my collegues are complaining about in IzPack.
>
>>
>> - It is possible to integrate 3rdParty Loging Products such as log4j.
>> -to break a butterfly on a wheel ;-)
>
>Log4j has a lot of options - given that it's a fully-fledged 
>logging package, 
>it should. At it's base, though, it's really only the 
>inclusion of a jar and 
>a series of single method calls in the client code.
>
>I should add a disclaimer :). We use it at work, and I have 
>had to hack the 
>ode a bit for our own uses, some time ago, so I am reasonably 
>familiar with 
>the package. Theere's on properties file that is used to drive 
>it, which is 
>certainly no more complicated than the configuration required 
>to IzPack 
>itself.
>

We you also log4j in our company. But the difference to IzPack is,
that we install the needed jars. Up to now most IzPack installations 
depends only on a VM not on any additional jar file. Therefore
needed class files are packed into the installation jar file (like the 
nano XML parser). The base install engine needs about 500KB. With 
log4j it will be ~ 220 KB more. In opposite to e.g. ant this will
be not optional, or will it?


>>
>> - Or to use the new Java.Logging classes functionality, 
>which are to new in
>> my opinion.
>
>I disagree.  Logging as part of the JDK has been around from 
>Java 1.4, and 1.5 
>is now in use. It has the advantage of being part of the JDK, 
>obviating the 
>need for any external dependency.
>

Since 3.8 we support VM version >= 1.4, therefore it should be
no problem to use it. May be log4j is better, but with the VM
resolution the jar file will not grow and we have no packaging
problems.

>>
>> - Or to implentend and integrate a self-implemented and lightweight
>> solution maybe as derived a solution of the current Debug-Class.
>>
>> I would prefer a mixed solution: integrate borrowed / 
>adapted code from
>> Jog4J to meet what we need.- To hold this lightweight Installer as
>> Lightweight Installer ;-)
>>
>> But I also would vote for an own independed solution if easy 
>adaptable /
>> expandable in future.
>
>
>A custom solution may be more lightweight, and in-house code 
>might be more 
>conducive to flexibility in changing the solution, but carries 
>with it the 
>problem we have had at my workplace - you have to maintain a 
>logging product 
>of sorts. I'd rather break a butterfly on a wheel than 
>reinvent the wheel, 
>and have to roll it :)
> 

If it needs no investment to use the wheel, I will use it also
I need only a little bit from it.

>Personally, I'd plump for java.util.logging as first choice, 
>followed by 
>log4j, and an in-house solution last.
>
>Eric
>
>-- 
>Eric Rose              | "Sed quis custodiet ipsos custodes?"
>eric at integeo.com       |         Juvenal (Satires, VI.347-8)
>
>***********************************************************************
>This message contains privileged and confidential information intended
>only for the use of the addressee named above.  If you are not the
>intended recipient of this message you must not disseminate, copy or
>take any action in reliance on it.  If you have received this message
>in error please notify the sender immediately.  Any views expressed in
>this message are those of the individual sender, except where the
>sender specifically states them to be the views of another (including
>a Body Corporate).
>
>If you wish to opt out from future messages, send an email to
>unsubscribe at integeo.com with the subject UNSUBSCRIBE
>***************************************************************
>*********
>
>