This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, Our web application sends in Request XMLs to another remote server and receives response XMLs from the server. Currently these 2 xmls, the request and response xmls are written out to the standard output log file. But this makes log file huge and unfriendly. So what is a better design ? I was thinking of creating a database table and for transactions, create an entry in the database. What are the other options ? I need to give a couple of solutions. so please suggest. Thanks Maya
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 ]