[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469453
]
Daniel John Debrunner commented on DERBY-1275:
----------------------------------------------
That's the general idea, at least for existing decorators returned by
TestConfiguration, but I'm curious as to why you feel in this case the static
method is useful or required.
A class can be used as a decorator, just using
new SystemPropertyTestSetup(suite, newProperties)
which is actually less to type than
TestDecorator.systemPropertiesSetupDecorator(suite, newProperties)
Then exposing the class as the decorator actually allows tests to customize it.
Typically a test may want to perform additional setup or teardown based upon an
existing decorator. Java allows this without having to define an additional
class
explicitly.
For example see CleanDatabaseTestSetup, which allows a test to use it in-line
and easily add DDL statements. This is from the javadoc for
CleanDatabaseTestSetup.
return new CleanDatabaseTestSetup(suite) {
protected void decorateSQL(Statement s) throws SQLException {
s.execute("CREATE TABLE T (I INT)");
s.execute("CREATE INDEX TI ON T(I)")
}
};
If the CleanDatabaseTestSetup was exposed as a static method then this style of
customization is no longer possible.
Exposing it as a class and a static method has the downside of multiple ways to
perform the same task, which tends to make it harder for people to add tests,
e.g. which way should I use?
> 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,
> DERBY1275EnableClientTracingDiffV3.txt,
> DERBY1275EnableClientTracingDiffV4.txt,
> DERBY1275EnableClientTracingStatV1.txt,
> DERBY1275EnableClientTracingStatV2.txt,
> DERBY1275EnableClientTracingStatV3.txt, DERBY1275EnableClientTracingStatV4.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.
