|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 3882 | minor | always | 02-09-10 09:23 | 02-09-10 09:32 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | ferg | OS: | |||
| Priority: | normal | OS Version: | |||
| Status: | closed | Product Version: | 4.0.3 | ||
| Product Build: | Resolution: | fixed | |||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 4.0.4 | ||
|
|
|||||
| Summary: | 0003882: EnvironmentLogger getHandlers must not return null | ||||
| Description: |
(rep by Knut Forkalsrud) I believe I have found a bug. The situation is a webapp with BerkeleyDB[1] (from Sleepycat software, now Oracle). Running it in Resin 3.1.8 fails during initialization and the culprit is the method com.caucho.log.EnvironmentLogger.getHandlers(). BerkeleyDB plays around with the loggers (java.util.logging) and the expectation[2] in the code base is that an array is always returned from getHandlers(), never null. That seems to be a valid assumption, the method in EnvironmentLogger overrides a method in java.util.logging.Logger[3], which does indeed make sure return an empty array instead of null. >From what I can tell the fix is relatively simple, unless I am mistaken it is just a matter of making the default value an empty array. In other words the constructor of EnvironmentLogger should call: _localHandlers.setGlobal(new Handler[0]); That approach could affect how "parent" environments work, so maybe the fix should be a little bit more like the implementation in java.util.logging.Logger. I don't understand the code well enough to make that judgement. The workaround is not entirely simple, I ended up grabbing all 8 loggers used by BerkeleyDB in this configuration and add a dummy handler to each of them. |
||||
| Steps To Reproduce: | |||||
| Additional Information: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||