[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468079
]
Daniel John Debrunner commented on DERBY-1275:
----------------------------------------------
Some quick comments on the patch:
ClientSideSystemProperties JUnit test
The test breaks the pattern for JUnit tests in a few ways:
- the suite method performs test setup. The suite method is for providing a
set of fixtures to run. Setup should be performed in a test decorator for a set
of fixtures or the setUp method for each fixture.
- the actual testing, the asserts, is performed in the tearDown method, but is
expected to be in the fixture methods, the ones that usually start with 'test'.
tearDown should be for cleanup after a fixture run.
- JUnit guidelines have JUnit test classes ending with 'Test', Derby seems to
follow this.
I had some more comments that I lost on the privilege actions but I need to run
now.
> Provide a way to enable client tracing without changing the application
> -----------------------------------------------------------------------
>
> Key: DERBY-1275
> URL: https://issues.apache.org/jira/browse/DERBY-1275
> Project: Derby
> Issue Type: Improvement
> Components: Network Client
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assigned To: Mamta A. Satoor
> Priority: Minor
> Fix For: 10.2.3.0
>
> Attachments: DERBY1275EnableClientTracingDiffV1.txt,
> DERBY1275EnableClientTracingDiffV2.txt,
> DERBY1275EnableClientTracingStatV1.txt, DERBY1275EnableClientTracingStatV2.txt
>
>
> Currently the client tracing can be enabled by setting attributes on the
> client url, setXXX methods on the DataSource or calling
> DriverManager.setLogWriter(), but it often cannot be enabled in a deployed
> client application because all of these API's require modification of the
> application or its configuration files.
> It would be good to have a global way to turn on client tracing. A system
> property pointing to a property file is one possibility but probably not
> ideal because of the impact in class loader contexts. I am not sure what
> the other possiblities are,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
