logging for analysis

Discussion in 'Java' started by Jeff Kish, Jan 22, 2008.

  1. Jeff Kish

    Jeff Kish Guest

    Hi.

    I'm still relatively new to java.
    I am trying to analyze and figure out on my own how a
    proprietary frameworks 'works'.

    It is event driven, and I tried putting a bunch of System.out.println
    statements in, but:
    1 - because (i come from c++ background) there are no destructors I
    don't know for sure when things 'go away'
    2 - everytime (it is still being developed) I get a bunch of debug in,
    I use it for a day or two (yes it takes me that long to figure out
    stuff .. my memory is kind of overloading) and then I have to get a
    new version and put everything in all over again.

    Does anyone have a suggestion on how to go about analyzing this?
    I find there are a hand full of objects (session, etc) that have a
    handful of important methods (handleTheEvent(...) etc) that are worth
    logging.

    I'd like to be able to output to a log file of some sort information
    so I can play back a visualization of the events as they are fired and
    handled by objects and their descendents.

    I hope this isn't too much. I appreciate any thoughts.

    thanks
    Jeff
     
    Jeff Kish, Jan 22, 2008
    #1
    1. Advertising

  2. Java tends to eliminate much of the junk that C++ has ie. memory
    management. By that I don't mean do something like declare an array
    for all 16 million colors (I did that once :). Also by destructors I
    think you might mean the finalise method in classes.
     
    Chase Preuninger, Jan 23, 2008
    #2
    1. Advertising

  3. Jeff Kish

    Jeff Kish Guest

    On Tue, 22 Jan 2008 17:23:54 -0800 (PST), Chase Preuninger
    <> wrote:

    >Java tends to eliminate much of the junk that C++ has ie. memory
    >management. By that I don't mean do something like declare an array
    >for all 16 million colors (I did that once :). Also by destructors I
    >think you might mean the finalise method in classes.

    Thanks. Any suggestions for an approach to logging event creation and
    handling in a frameworks so I can go back later and visualize it?

    I'd appreciate feedback in either the logging or visualization or
    both.

    regards
    Jeff
     
    Jeff Kish, Jan 23, 2008
    #3
  4. Jeff Kish

    Lew Guest

    Chase Preuninger wrote:
    > Java tends to eliminate much of the junk that C++ has ie. memory
    > management. By that I don't mean do something like declare an array
    > for all 16 million colors (I did that once :). Also by destructors I
    > think you might mean the finalise method in classes.


    Aaaagh! Don't recommend finalizers! And they are most definitely *not* like
    destructors - not even slightly.

    Java neither has nor needs destructors. Nor anything similar.

    Finalizers come with a *huge* penalty and *lots* of danger, and almost never
    are needed.

    There should be no problem declaring an array of 16M colors.

    --
    Lew
     
    Lew, Jan 23, 2008
    #4
  5. Jeff Kish

    Lew Guest

    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
     
    Lew, Jan 23, 2008
    #5
  6. Jeff Kish

    Lew Guest

    Chase Preuninger wrote:
    >> Also by destructors I
    >> think you might mean the finalise [sic] method in classes.


    There is no "finalise" method in the standard API.

    <http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize()>

    --
    Lew
     
    Lew, Jan 23, 2008
    #6
  7. Jeff Kish

    Jeff Kish Guest

    On Tue, 22 Jan 2008 21:31:26 -0500, Lew <> wrote:

    >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.

    mm I guess I didn't even think of System.err, is there a distinct
    advantage to that?

    Do you have any thoughts or recommendations to visualizing the
    'captured' log records?

    thanks
    again
     
    Jeff Kish, Jan 26, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stefan Siegl
    Replies:
    0
    Views:
    975
    Stefan Siegl
    Aug 27, 2003
  2. janne
    Replies:
    0
    Views:
    9,571
    janne
    Sep 10, 2004
  3. Victor

    Logging analysis tool

    Victor, Nov 12, 2004, in forum: Java
    Replies:
    1
    Views:
    365
    Thomas Weidenfeller
    Nov 12, 2004
  4. Christoph Haas
    Replies:
    0
    Views:
    471
    Christoph Haas
    Jun 12, 2006
  5. ssubbarayan
    Replies:
    5
    Views:
    2,393
    Dave Hansen
    Nov 3, 2009
Loading...

Share This Page