Re: logging for analysis
Jeff Kish wrote:
I'd appreciate feedback in either the logging or visualization or
both.
Logging:
log4j
<http://logging.apache.org/>
java.util.logging
<http://java.sun.com/javase/6/docs/api/java/util/logging/package-summary.html>
Both can be reconfigured at deployment time to give greater or lesser detail,
on a class-by-class basis even. I am more familiar with log4j myself.
At least with log4j, and I suspect with the Java package also, you can
configure outputs to go to a console, a file, wherever, even simultaneously.
log4j has hooks to handle multi-threaded programs, too.
The overhead of a logging call when the detail level isn't fine enough for it
to emit anything is quite small.
Make sure when you design your logging strategy that you think about what
operations will need when the program is deployed. Good logging will make
maintenance much easier, and downtime much rarer.
It is event driven, and I tried putting a bunch of System.out.println
statements in, but:
Why not System.err?
1 - because (i [sic] come from c++ background) there are no destructors I
don't know for sure when things 'go away'
They go away when the JVM decides they should. Only orphaned objects go away
- keeping a reference to an object will keep it from being garbage collected.
Kept references are Java's equivalent to memory leaks.
--
Lew