[
https://issues.apache.org/jira/browse/DERBY-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erlend Birkenes updated DERBY-3618:
-----------------------------------
Attachment: DERBY-3618_2.diff
- Added license header
- changed org.apache.derbyTesting.functionTests.harness.JavaVersionHolder to
org.apache.derby.iapi.services.info.JVMInfo
- changed to check to see if Monitor.getStream() is null instead of catching
the NullPointerException.
Still haven't done anything about testing this. I can't see that there is
anything that we really need to test here. The ThreadDump class is very basic
and uses only standard java methods and shouldn't need testing.
In AssertFeilure we just take the dump-string and pass it on to
Monitor.getStream().getPrintWriter(). Isn't it the Monitors job to set up the
output stream correctly? If the PrintWriter points to derby.log it'll work and
if it points to System.err or somewhere else then it's probably because
derby.log doesn't exist or there is another good reason for it. In any case
there will always be a PrintWriter to write to. But testing that writing to the
log file works correctly should be tested elsewhere. We should be able to trust
that Monitor.getStream().getPrintWriter() can deal with any string correctly.
Is there anything else we need to test here?
> Perform thread dump with ASSERTS with jdk 1.5 or higher
> -------------------------------------------------------
>
> Key: DERBY-3618
> URL: https://issues.apache.org/jira/browse/DERBY-3618
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.5.0.0
> Reporter: Kathey Marsden
> Assignee: Erlend Birkenes
> Priority: Minor
> Attachments: DERBY-3618_1.diff, DERBY-3618_2.diff
>
>
> It would be good to have a stack traces for all threads dump to the derby.log
> when an assertion occurs with JVM's that support it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
