
|
If you were logged in you would be able to see more operations.
|
|
|
| Severity: |
Incorrectly Functioning with Workaround
|
| Reproducibility: |
Every Time
|
| Discoverability: |
Medium
|
| Found in Version: |
SDK Flex 3 (Released)
|
| Affected OS(s): |
All OS Platforms
|
| Steps to Reproduce: |
mx.logging.AbstractTarget#set level() calls Log#removeTarget() without first checking if there are any loggers. Then #removeLogger() does not check if the logger count is zero, thereby setting the logger count to -1.
Once #set level exits, the loggerCount is zero, although a listener was added.
Compare with AbstractTarget#set filters(), which first checks if there are any loggers.
The logger count must be in sync with the number of event listeners added to the logger, otherwise strange things happen, such as duplicate log entries, although only one logger is active.
Workaround (if any):
Calling Log.addTarget(target) before setting the target's level avoids the problem of setting the logger count to -1.
mx.logging.AbstractTarget#set level() calls Log#removeTarget() without first checking if there are any loggers. Then #removeLogger() does not check if the logger count is zero, thereby setting the logger count to -1.
Once #set level exits, the loggerCount is zero, although a listener was added.
Compare with AbstractTarget#set filters(), which first checks if there are any loggers.
The logger count must be in sync with the number of event listeners added to the logger, otherwise strange things happen, such as duplicate log entries, although only one logger is active.
Workaround (if any):
Calling Log.addTarget(target) before setting the target's level avoids the problem of setting the logger count to -1.
|
| Language Found: |
English
|
| Bugbase Id: |
none
|
| QA Owner: |
Joan Lafferty
|
| Participants: |
Joan Lafferty and Jürgen Failenschmid
|
|
All
|
Comments
|
|
Sort Order:
|
| There are no comments yet on this issue.
|
|