first thing : decouple the handling of the log from its persistence. this will mean that the client side stays the same however you implement the persistence side. an easy way to do this is to use a standard logging framework for the client(application) side of the log. don't write your own - it is unlikely that yr logging needs are different from anyone else's. log4j (now apache at
http://jakarta.apache.org/log4j, but originally developed by IBM) is often considered the best by developers, then there is jlog (also developed by an IBMer) but was the basis for JSR47 which i am told became the logging included jdk1.4. some runtimes (e.g. portal servers, web servers), provide their own, probably optimised, logging services. you pick. but for sure stay away from System.out - these are blocking calls and yr application stops while it makes them!!
second : on the persistence side, well a database would be good if you want to recover data on logs using SQL, but this will not be free (nothing is). most people would probably says that a rolling text log that can be grep'd, would give good flexibility at low cost. but you'll find that any good logging framework will give you the flexibility to write contextually to >1 storage media. suggest : work back from how people will need to interact with the log to decide how "mature" the persistence technology needs to be.
hope this helps,
peter
[ June 16, 2003: Message edited by: peter greaves ]