Skip to main content
Last updated January 01, 2014 19:18, by Ernie Rael
Feedicon  

Future Development

Bug reports

depends on feedback

TODO list

Bugs
    -  validate values... OP_TARGET,OP_PATTERN are left.

Bugs that probably can't happen
    - Ref logger so it doesn't disapear as we're trying to modify it.
      Almost impossible, may not be a bug since logger's create on demand.
    - holes in handler IDs. (probably only a theoretical bug)
    - When replaying, changes that don't change anything are not included
      (effectively tossed out). They shouldn't be.
      Only way this can happen is a bug or program changes something.
    - Validation layout bug if start with error on CreateLoggerByName (root).

Cleanup Features
    - Internationalize
    - jLogMan logo. Scroll with "jLogMan" or some such.
*   - In NB, keep prefs for size/loc of dialog.
    - Add a LogManager listener (through logCom).
      Bring up a dialog somehow, maybe if has focus or when gets focus.
    - Use a getProperty method to pick up some defaults,
      first try, go to LogManager, but see Features below for future...
    - Finish handler delete. Works for usr, do it for pgm
    - Put '*' on created logger, turn it into '+' if deleted but referenced
      Even though loggers are on demand, having this makes it obvious
      that "delete logger" would do something to the config.
      Slightly different color background in table?
    - In clearConfig, why do refresh?
    - Don't rebuild from scratch. Use Tim's tree/list compare.

Internal
    - Instead of parse(string), could have parse(Reader). Then input
      straight from File or String, make a reader for Map.
      Keep track of line number.
    - I keep debating on whether the create op should be ouput.
      Probably best to output, then have a export Action if ever want
      LogManager compatible properties. See changesAsString
    - Loggers and Handlers should only be accessed throgh LogCom.
      HandlerDelegates should only come from there (or other Handler
      Delegates). Use handler delegates consistently in all the code.
    - Add timer INFO to LogManActions (MyAbstractAction).
*   - MAVEN (Nexus)

UI
    - Have actions listen to selection, automatically enable/disable.
*   - add (optional) menu to dialog
    - more columns, e.g. encoding or inherit from logger, separate useParHan.
      Option to overload the effective column, (push level instead of encode)
    - delete ops UI.list of Ops, delete elements -or- delete checkbox/item.
    - buttons (optional): refresh, garbage collect.
    - combobox editor not quite right

Trivial Features (may be mostly UI work)
    - memory hanlder dynamic push
    - Modify encoding, other handler args (e.g. memory handler)
    - Modify hanlder
    - ? about action (menu item)

Features
    - Delete logger (and associated ops).
      Delete any ops/changes from config
    - Share/use same handler on more than one logger.
    - Work with properties like: java.util.logging.ConsoleHandler.level.
      optionally init from a file, auto read at startup.
      UI to set up the file.
      Create handler/logger uses these for defaults.
    - Scan for handlers/formatters/filters... on path;
      maybe separate UI to use them. maybe options in current UI. both?
    - Auto refresh function: timer, end of usr action
      (?ui recent items, list comment/details)
    - Track ops that couldn't apply, e.g. change to handler that isn't.
      Have way to apply them later: off a timer, button, usr activity
    - Support assigning an ErrorManager to a Handler when creating.
      Probably set on the LogTree. LogCom issues...
    - Memory handler create allow creation of specified class.
    - Have an optional ConfigFilter with some simple options.
    - On every write to logger/handler make sure it still exists. (?)

Major Features
    - undo/redo
    - Append file to current configuration.
      Issue with handling ID assigns since two files might have same IDs.
      Last applied wins, option to toss something already modified?
    - Save/Read logging.properties as defined in LogManager class doc.
      See item under internal about create op.
    - Have a log viewer.
      When working with xml output, have formatting options.
      Have a handler that sends the data to LogMan for viewing dynamically.
    - Replacement for LogManager
    - "Emergency" loggers that inspect/reflect to get values to log. Might be
      triggered when a particular class/method logger reports.
    - Compatibility with  multiple loggers, e.g. log4j. Not sure how feasable
      this is. Would wan them all to look the same...
      Maybe just SLF4J (Simple Logging Facade for Java).

Restricted/remote Feature
    - Could implement control operations on groups of Loggers when isRestricted.
    - Cache values from remote system. Provide a hook that runs on remote
      for full jLogMan management.

Code docs
    - use shadow handlers
    - notes on validation

User docs
    - ConfigFormatter

 
 
Close
loading
Please Confirm
Close