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
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.


Mime
View raw message