Bug reports
depends on feedback
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