org.das2.util.LoggerManager
Central place that keeps track of loggers. Note that both org.das.datum
and org.das2.datum have this same class, which is there to avoid coupling between the
packages.
LoggerManager( )
addHandlerToAll
addHandlerToAll( java.util.logging.Handler handler ) → void
Add the handler to all loggers created by this manager, and all
future. Only call this once! I would think that adding a handler to
the root would essentially add the handler to all loggers, but it doesn't
seem to.
Parameters
handler - e.g. GraphicalLogHandler
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
clearTimer
clearTimer( ) → void
explicitly remove this timer.
Returns:
void (returns nothing)
See Also:
resetTimer()
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
getLogger
getLogger( String id ) → java.util.logging.Logger
return the requested logger, but add it to the list of known loggers.
Parameters
id - the name
Returns:
the Logger
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
getLoggers
getLoggers( ) → java.util.Set
return the list of known loggers.
Returns:
the list of known loggers.
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
isEnableTimers
isEnableTimers( ) → boolean
return enableTimers property.
Returns:
enableTimers property.
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
isUseTimeTaggingLoggers
isUseTimeTaggingLoggers( ) → boolean
are we keeping track of log message times, so we can sort loggers by
how recently messages were posted?
Returns:
true if we are keeping track of log message times.
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
logExitGuiEvent
logExitGuiEvent( java.awt.event.ActionEvent e ) → void
call this at the end of the GUI event to measure time to respond.
Parameters
e - the focus event.
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
logExitGuiEvent( javax.swing.event.ChangeEvent e ) → void
logExitGuiEvent( java.awt.event.ItemEvent e ) → void
logExitGuiEvent( java.awt.event.FocusEvent e ) → void
logGuiEvent
logGuiEvent( java.awt.event.ActionEvent e ) → void
provide easy way to log all GUI events.
Parameters
e - an ActionEvent
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
logGuiEvent( javax.swing.event.ChangeEvent e ) → void
logGuiEvent( java.awt.event.ItemEvent e ) → void
logGuiEvent( java.awt.event.FocusEvent e ) → void
logPropertyChangeEvent
logPropertyChangeEvent( java.beans.PropertyChangeEvent e ) → void
log property change events. (I realized I spend a lot of time debugging walking
through the property change fire event code, and I should just add a
log message to all propertyChange codes.)
Parameters
e - a PropertyChangeEvent
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
logPropertyChangeEvent( java.beans.PropertyChangeEvent e, String source ) → void
markTime
markTime( ) → void
mark the time using the thread name.
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
markTime( String message ) → void
readConfiguration
readConfiguration( ) → void
A slightly more transparent logging configuration would provide feedback
about what configuration file it's loading. This will echo
when the configuration file would be.
The idea is when you are completely frustrated with not getting the logger
to behave, you can add:
org.das2.util.LoggerManager.readConfiguration()
to your code.
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
readConfiguration( String configfile ) → void
resetTimer
resetTimer( ) → void
reset the timer. The lifecycle is like so:
- LoggerManager.setTimerLogfile("/tmp/mylogfile.txt")
- LoggerManager.resetTimer("big task");
- LoggerManager.markTime("done loading");
- LoggerManager.markTime("calculated data");
- LoggerManager.clearTimer();
Note the timers are stored with weak references to the threads, so
clearTimer needn't be called.
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
resetTimer( String task ) → void
setEnableTimers
setEnableTimers( boolean enableTimers ) → void
if enableTimers is true, then resetTimer and markTime have
an effect. Each thread can have a timer to measure the execution
time for a process.
Parameters
enableTimers - true to enable timers
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
setTimerLogfile
setTimerLogfile( String f ) → void
channel the logging information to here, setEnableTimers(false) to close.
Parameters
f - a String
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]
setUseTimeTaggingLoggers
setUseTimeTaggingLoggers( boolean t ) → void
Parameters
t - a boolean
Returns:
void (returns nothing)
[search for examples]
[view on GitHub]
[view on old javadoc]
[view source]