db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Date Thu, 01 Feb 2007 15:20:05 GMT

    [ 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

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

> 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:,
>            Reporter: Kathey Marsden
>         Assigned To: Mamta A. Satoor
>            Priority: Minor
>             Fix For:
>         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.

View raw message