Derby
  1. Derby
  2. DERBY-1275

Provide a way to enable client tracing without changing the application

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.1.3.1, 10.2.1.6
    • Fix Version/s: 10.3.1.4
    • Component/s: Network Client
    • Labels:
      None
    • Urgency:
      Normal

      Description

      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,

      1. DERBY1275EnableClientTracingDiffV1.txt
        4 kB
        Mamta A. Satoor
      2. DERBY1275EnableClientTracingDiffV2.txt
        16 kB
        Mamta A. Satoor
      3. DERBY1275EnableClientTracingDiffV3.txt
        17 kB
        Mamta A. Satoor
      4. DERBY1275EnableClientTracingDiffV4.txt
        16 kB
        Mamta A. Satoor
      5. DERBY1275EnableClientTracingDiffV5.txt
        15 kB
        Mamta A. Satoor
      6. DERBY1275EnableClientTracingStatV1.txt
        0.3 kB
        Mamta A. Satoor
      7. DERBY1275EnableClientTracingStatV2.txt
        0.5 kB
        Mamta A. Satoor
      8. DERBY1275EnableClientTracingStatV3.txt
        0.5 kB
        Mamta A. Satoor
      9. DERBY1275EnableClientTracingStatV4.txt
        0.5 kB
        Mamta A. Satoor
      10. DERBY1275EnableClientTracingStatV5.txt
        0.5 kB
        Mamta A. Satoor

        Issue Links

          Activity

          Gavin made changes -
          Workflow jira [ 12361892 ] Default workflow, editable Closed status [ 12801395 ]
          Hide
          Kathey Marsden added a comment -

          I linked the issue that made the permissions optional. It is fine for this issue to be closed.

          Show
          Kathey Marsden added a comment - I linked the issue that made the permissions optional. It is fine for this issue to be closed.
          Kathey Marsden made changes -
          Link This issue relates to DERBY-2754 [ DERBY-2754 ]
          Hide
          Myrna van Lunteren added a comment -

          Kathey, did you make the permissions optional or not? Should this bug be closed?

          Show
          Myrna van Lunteren added a comment - Kathey, did you make the permissions optional or not? Should this bug be closed?
          Hide
          Kathey Marsden added a comment -

          Running the 10.2 tests against 10.3 ( DERBY-2743) there are quite a few failures in network server tests because of
          AccessControlException: Access denied java.util.Property derby.client.traceLevel read

          Especially since these are undocumented properties, I think a security exception trying to read the property should not be fatal. If noone objects, I will file a separate issue to make the permission optional.

          Show
          Kathey Marsden added a comment - Running the 10.2 tests against 10.3 ( DERBY-2743 ) there are quite a few failures in network server tests because of AccessControlException: Access denied java.util.Property derby.client.traceLevel read Especially since these are undocumented properties, I think a security exception trying to read the property should not be fatal. If noone objects, I will file a separate issue to make the permission optional.
          Kathey Marsden made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Mamta A. Satoor added a comment -

          Laura, the current thought is to keep this as an undocumented addition to Derby. There is information on this addition at http://wiki.apache.org/db-derby/UndocumentedDerbyBehavior if a user wants to go ahead and use it until some another way of on the fly client tracing is enabled, ie w/o changing the application.

          If the community thinks it is ok to go ahead and make the properties introduced in my solution as an official solution then we can go ahead and add it to Derby's official docs.

          Show
          Mamta A. Satoor added a comment - Laura, the current thought is to keep this as an undocumented addition to Derby. There is information on this addition at http://wiki.apache.org/db-derby/UndocumentedDerbyBehavior if a user wants to go ahead and use it until some another way of on the fly client tracing is enabled, ie w/o changing the application. If the community thinks it is ok to go ahead and make the properties introduced in my solution as an official solution then we can go ahead and add it to Derby's official docs.
          Hide
          Laura Stewart added a comment -

          Can you help me understand what, if anything, needs to be documented in the Derby books about this issue?

          Show
          Laura Stewart added a comment - Can you help me understand what, if anything, needs to be documented in the Derby books about this issue?
          Hide
          Mamta A. Satoor added a comment -

          Dan, to answer your question about some existing test to test the tracing through JDBC attribute, we do have one, jdbcapi/checkDriver but this test is not a junit test and does not run under the security manager and hence has not run into permission issues.

          I will work on the policy changes that might be required for derbyclient.jar because currently it can only read properties starting with derby.*
          permission java.util.PropertyPermission "derby.*", "read";

          Show
          Mamta A. Satoor added a comment - Dan, to answer your question about some existing test to test the tracing through JDBC attribute, we do have one, jdbcapi/checkDriver but this test is not a junit test and does not run under the security manager and hence has not run into permission issues. I will work on the policy changes that might be required for derbyclient.jar because currently it can only read properties starting with derby.* permission java.util.PropertyPermission "derby.*", "read";
          Hide
          Daniel John Debrunner added a comment -

          I think it would be good to figure out why this permission is needed now. If previously we were running tests under the security manager that set tracing via the JDBC attributes, then this new functionality should not require any additional permissions. Of course we may have not been testing tracing at all or maybe not under the security manager?

          Show
          Daniel John Debrunner added a comment - I think it would be good to figure out why this permission is needed now. If previously we were running tests under the security manager that set tracing via the JDBC attributes, then this new functionality should not require any additional permissions. Of course we may have not been testing tracing at all or maybe not under the security manager?
          Hide
          Knut Anders Hatlen added a comment -

          The tinderbox test has failed since the patch was committed. Seems like derbyclient.jar needs permission to read the user.dir property. I guess we only see this failure when running the tests from the jar files, since the classes directory already has permission to read that property.

          http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/504394-org.apache.derbyTesting.functionTests.suites.All_diff.txt

          Show
          Knut Anders Hatlen added a comment - The tinderbox test has failed since the patch was committed. Seems like derbyclient.jar needs permission to read the user.dir property. I guess we only see this failure when running the tests from the jar files, since the classes directory already has permission to read that property. http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/504394-org.apache.derbyTesting.functionTests.suites.All_diff.txt
          Mamta A. Satoor made changes -
          Resolution Fixed [ 1 ]
          Derby Info [Patch Available]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Mamta A. Satoor added a comment -

          Commiting patch DERBY1275EnableClientTracingDiffV5.txt as part of revision 504317. This patch adds 2 JVM properties to enable client side tracing. The properties are derby.client.traceLevel and derby.client.traceDirectory
          More info can be found at http://wiki.apache.org/db-derby/UndocumentedDerbyBehavior

          Show
          Mamta A. Satoor added a comment - Commiting patch DERBY1275EnableClientTracingDiffV5.txt as part of revision 504317. This patch adds 2 JVM properties to enable client side tracing. The properties are derby.client.traceLevel and derby.client.traceDirectory More info can be found at http://wiki.apache.org/db-derby/UndocumentedDerbyBehavior
          Mamta A. Satoor made changes -
          Fix Version/s 10.3.0.0 [ 12310800 ]
          Fix Version/s 10.2.3.0 [ 12312215 ]
          Mamta A. Satoor made changes -
          Attachment DERBY1275EnableClientTracingDiffV5.txt [ 12350233 ]
          Attachment DERBY1275EnableClientTracingStatV5.txt [ 12350234 ]
          Hide
          Mamta A. Satoor added a comment -

          Have taken care of the last outstanding issue about the junit test. Now the suite() method directly accesses the SystemPropertyTestSetup to set the system properties. The review package is attached as DERBY1275EnableClientTracingDiffV5.txt. If there are no further comments, i will look into committing this patch early next week.

          Show
          Mamta A. Satoor added a comment - Have taken care of the last outstanding issue about the junit test. Now the suite() method directly accesses the SystemPropertyTestSetup to set the system properties. The review package is attached as DERBY1275EnableClientTracingDiffV5.txt. If there are no further comments, i will look into committing this patch early next week.
          Hide
          Mamta A. Satoor added a comment -

          I think I misunderstood your following comment on Jan 27th to the review package DERBY1275EnableClientTracingDiffV2.txt
          "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. "

          I took the above comment to mean that Junit pattern discourages following setup code in the suite() method
          Properties traceRelatedProperties = new Properties();
          traceRelatedProperties.setProperty("derby.client.traceLevel", "64");
          traceDirectory = "." + File.separator + "TraceDir" + File.separator;
          traceRelatedProperties.setProperty("derby.client.traceDirectory", traceDirectory);
          return new SystemPropertyTestSetup(suite, traceRelatedProperties);

          Now, I think your comment was really for following piece of code in the suite() method and not for the code related to SystemPropertyTestSetup fixture.
          + File dir = new File( traceDirectory );
          + dir.mkdirs();

          This is the only outstanding issue that I need to resolve on this Jira entry based on all different comments. I have already moved the directory setup code in the setUp() method in the .DERBY1275EnableClientTracingDiffV4.txt Next, I will remove systemPropertiesSetupDecorator from TestConfiguration and have my junit test directly use the fixture SystemPropertyTestSetup.

          Show
          Mamta A. Satoor added a comment - I think I misunderstood your following comment on Jan 27th to the review package DERBY1275EnableClientTracingDiffV2.txt "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. " I took the above comment to mean that Junit pattern discourages following setup code in the suite() method Properties traceRelatedProperties = new Properties(); traceRelatedProperties.setProperty("derby.client.traceLevel", "64"); traceDirectory = "." + File.separator + "TraceDir" + File.separator; traceRelatedProperties.setProperty("derby.client.traceDirectory", traceDirectory); return new SystemPropertyTestSetup(suite, traceRelatedProperties); Now, I think your comment was really for following piece of code in the suite() method and not for the code related to SystemPropertyTestSetup fixture. + File dir = new File( traceDirectory ); + dir.mkdirs(); This is the only outstanding issue that I need to resolve on this Jira entry based on all different comments. I have already moved the directory setup code in the setUp() method in the .DERBY1275EnableClientTracingDiffV4.txt Next, I will remove systemPropertiesSetupDecorator from TestConfiguration and have my junit test directly use the fixture SystemPropertyTestSetup.
          Hide
          Daniel John Debrunner added a comment -

          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?

          Show
          Daniel John Debrunner added a comment - 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?
          Hide
          Mamta A. Satoor added a comment -

          Dan, I think I understand the Decorator class comment. It seems that the purpose of TestConfiguration class is to have static methods which will do some setup related things and then return an instance of a decorator based on that (eg sqlAuthorizationDecorator() method sets up the sqlAuthorization property and then passes it on to the decorator DatabaseChangeSetup). But the static method I added simply returns an instance of the decorator using the parameters passed to the static method. And hence it doesn't fit the definition of the TestConfiguration class.

          I will add another class called say, TestDecorator. I will move my following method from TestConfiguration class to the new TestDecorator class. Is this what you were proposing?
          public static Test systemPropertiesSetupDecorator(Test suite, Properties newProperties)

          { return new SystemPropertyTestSetup(suite, newProperties); }
          Show
          Mamta A. Satoor added a comment - Dan, I think I understand the Decorator class comment. It seems that the purpose of TestConfiguration class is to have static methods which will do some setup related things and then return an instance of a decorator based on that (eg sqlAuthorizationDecorator() method sets up the sqlAuthorization property and then passes it on to the decorator DatabaseChangeSetup). But the static method I added simply returns an instance of the decorator using the parameters passed to the static method. And hence it doesn't fit the definition of the TestConfiguration class. I will add another class called say, TestDecorator. I will move my following method from TestConfiguration class to the new TestDecorator class. Is this what you were proposing? public static Test systemPropertiesSetupDecorator(Test suite, Properties newProperties) { return new SystemPropertyTestSetup(suite, newProperties); }
          Mamta A. Satoor made changes -
          Attachment DERBY1275EnableClientTracingStatV4.txt [ 12350108 ]
          Attachment DERBY1275EnableClientTracingDiffV4.txt [ 12350107 ]
          Hide
          Mamta A. Satoor added a comment -

          Dan, I have
          1)taken care of "." from the trace directory for portability reasons,
          2)removed the use of static field from the junit test and
          3)created a new method to fetch the system property rather than duplicating the code in 2 places in ClientBaseDataSource.

          All these changes are in DERBY1275EnableClientTracingDiffV4.txt. svn stat -q output hasn't really changed since the last attachement but I have copied it again ( DERBY1275EnableClientTracingStatV4.txt) to have svn stat -q output for every patch revision.

          As for your last comment about decorators, I am not 100% clear yet on what you are proposing. I will spend some more time in trying to figure it out.

          I will fire the junit test suite to make sure the patch attached doesn't cause any regression.

          Show
          Mamta A. Satoor added a comment - Dan, I have 1)taken care of "." from the trace directory for portability reasons, 2)removed the use of static field from the junit test and 3)created a new method to fetch the system property rather than duplicating the code in 2 places in ClientBaseDataSource. All these changes are in DERBY1275EnableClientTracingDiffV4.txt. svn stat -q output hasn't really changed since the last attachement but I have copied it again ( DERBY1275EnableClientTracingStatV4.txt) to have svn stat -q output for every patch revision. As for your last comment about decorators, I am not 100% clear yet on what you are proposing. I will spend some more time in trying to figure it out. I will fire the junit test suite to make sure the patch attached doesn't cause any regression.
          Hide
          Daniel John Debrunner added a comment -

          Patch looks cleaner - thanks. Some minor issue, could be addressed after commit:

          • traceDirectory = "." + File.separator + "TraceDir" + File.separator;

          I don't think use of '.' for the current directory is portable, I think you can simply use "TraceDir" here.

          • ClientSideSystemPropertiesTest
            private static String traceDirectory;

          Use of static fields in a JUnit test is not a good practice.
          Since the decorator will set the system property, you could just fetch the value of the system property when you need it.
          BaseTestCase has a utility method to do that.

          • In the client code the two identical anonymous inner classes could be combined into one to reduce footprint by having
            a private method in ClientBaseDataSource that gets the system property passed into it.
          • You added a method to TestConfiguration - systemPropertiesSetupDecorator.
            I guess I didn't understand what value this adds. The decorators that are returned from static methods
            in TestConfiguration are ones that modify the configuration, but where a decorator can be used directly
            it is left as, which I think maps to the typical use of decorators in Junit.
            I think maybe the TestConfiguration class has already come too intertwined with decorators and it might be better to have a Decorator class that just had static methods. This would at least gather them in a single class so that they could be easily discovered. I think a Decorator class would be a good place for the method you added.
          Show
          Daniel John Debrunner added a comment - Patch looks cleaner - thanks. Some minor issue, could be addressed after commit: traceDirectory = "." + File.separator + "TraceDir" + File.separator; I don't think use of '.' for the current directory is portable, I think you can simply use "TraceDir" here. ClientSideSystemPropertiesTest private static String traceDirectory; Use of static fields in a JUnit test is not a good practice. Since the decorator will set the system property, you could just fetch the value of the system property when you need it. BaseTestCase has a utility method to do that. In the client code the two identical anonymous inner classes could be combined into one to reduce footprint by having a private method in ClientBaseDataSource that gets the system property passed into it. You added a method to TestConfiguration - systemPropertiesSetupDecorator. I guess I didn't understand what value this adds. The decorators that are returned from static methods in TestConfiguration are ones that modify the configuration, but where a decorator can be used directly it is left as, which I think maps to the typical use of decorators in Junit. I think maybe the TestConfiguration class has already come too intertwined with decorators and it might be better to have a Decorator class that just had static methods. This would at least gather them in a single class so that they could be easily discovered. I think a Decorator class would be a good place for the method you added.
          Hide
          Mamta A. Satoor added a comment -

          I have added a page to Derby wiki for Derby's undocumented behavior. Goto page http://wiki.apache.org/db-derby/ and click on UndocumentedDerbyBehavior: under Derby Usage Information. It will take you to the page where the 2 new jvm properties are described with a pointer to the Jira entry. Please let me know if you have any feedback on the contents of the page and how the page is connected from the Derby wiki page.

          Show
          Mamta A. Satoor added a comment - I have added a page to Derby wiki for Derby's undocumented behavior. Goto page http://wiki.apache.org/db-derby/ and click on UndocumentedDerbyBehavior: under Derby Usage Information. It will take you to the page where the 2 new jvm properties are described with a pointer to the Jira entry. Please let me know if you have any feedback on the contents of the page and how the page is connected from the Derby wiki page.
          Mamta A. Satoor made changes -
          Derby Info [Patch Available]
          Mamta A. Satoor made changes -
          Attachment DERBY1275EnableClientTracingStatV3.txt [ 12349959 ]
          Attachment DERBY1275EnableClientTracingDiffV3.txt [ 12349958 ]
          Hide
          Mamta A. Satoor added a comment -

          I have attached a new patch DERBY1275EnableClientTracingDiffV3.txt which is based on Dan's comments on the earlier patch.

          What's different(high level) from the last patch (DERBY1275EnableClientTracingDiffV2.txt)

          Junit test
          1)The suite method now uses a decorator to set the system properties.
          2)The client tracing directory cleanup before the fixture testConnection is done is setUp and cleanup after the test is done in tearDown.
          3)The assert is now done in the fixture, testConnection.
          4)The junit class now ends with Test. The new name of the test is ClientSideSystemPropertiesTest.

          Code related to privilege block
          1)I have replaced the new classes for privilege blocks with anonymous inline classes.
          2)I hope that I have addressed the exception code related to PrivilegedActionException correctly.
          3)I have removed the synchronized from run() methods. I have to admit that I had them originally because some existing junit test had them(I don't remember offhand what test I checked).

          I have run the junit suite and there was no new errors.

          Show
          Mamta A. Satoor added a comment - I have attached a new patch DERBY1275EnableClientTracingDiffV3.txt which is based on Dan's comments on the earlier patch. What's different(high level) from the last patch (DERBY1275EnableClientTracingDiffV2.txt) Junit test 1)The suite method now uses a decorator to set the system properties. 2)The client tracing directory cleanup before the fixture testConnection is done is setUp and cleanup after the test is done in tearDown. 3)The assert is now done in the fixture, testConnection. 4)The junit class now ends with Test. The new name of the test is ClientSideSystemPropertiesTest. Code related to privilege block 1)I have replaced the new classes for privilege blocks with anonymous inline classes. 2)I hope that I have addressed the exception code related to PrivilegedActionException correctly. 3)I have removed the synchronized from run() methods. I have to admit that I had them originally because some existing junit test had them(I don't remember offhand what test I checked). I have run the junit suite and there was no new errors.
          Hide
          Daniel John Debrunner added a comment -

          privilege block comments:

          1) Use of classes for privilege blocks is ok but the typical use is anonymous classes, see BaseTestCase.getSystemProperty for an example.

          2) The exception handling for the privilege blocks is incorrect:

          • System.getProperty() in SystemPropertyReadPrivledgeBlock cannot thrown IOException or any checked exception so only a PrivilegedAction is needed and no need to catch java.security.PrivilegedActionException.
          • The java.security.PrivilegedActionException only catches checked exceptions which are not RuntimeExceptions so this code is incorrect:
            + } catch (java.security.PrivilegedActionException pae) {
            + throw (RuntimeException) pae.getException();
            For example opening a file in a privilge block can thrown IOException which will be wrapped in PrivilegedActionException but a SecurityException will not.
          • The error handling for FilePrivilegeBlock is broken. The run() method can throw IOException but if it does the cast to RuntimeException will cause another exception. Previously the exception would be wrapped in a SqlException. Typically the run() methods of a privilege action should be simple, so in this case the run() method should not be catching IOException and wrapping it in a SqlException, instead the wrapping should happen outside the doPrivileged() call.

          3) Any reason for the run() methods to be synchronized?

          Show
          Daniel John Debrunner added a comment - privilege block comments: 1) Use of classes for privilege blocks is ok but the typical use is anonymous classes, see BaseTestCase.getSystemProperty for an example. 2) The exception handling for the privilege blocks is incorrect: System.getProperty() in SystemPropertyReadPrivledgeBlock cannot thrown IOException or any checked exception so only a PrivilegedAction is needed and no need to catch java.security.PrivilegedActionException. The java.security.PrivilegedActionException only catches checked exceptions which are not RuntimeExceptions so this code is incorrect: + } catch (java.security.PrivilegedActionException pae) { + throw (RuntimeException) pae.getException(); For example opening a file in a privilge block can thrown IOException which will be wrapped in PrivilegedActionException but a SecurityException will not. The error handling for FilePrivilegeBlock is broken. The run() method can throw IOException but if it does the cast to RuntimeException will cause another exception. Previously the exception would be wrapped in a SqlException. Typically the run() methods of a privilege action should be simple, so in this case the run() method should not be catching IOException and wrapping it in a SqlException, instead the wrapping should happen outside the doPrivileged() call. 3) Any reason for the run() methods to be synchronized?
          Hide
          Daniel John Debrunner added a comment -

          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.

          Show
          Daniel John Debrunner added a comment - 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.
          Mamta A. Satoor made changes -
          Attachment DERBY1275EnableClientTracingDiffV2.txt [ 12349733 ]
          Attachment DERBY1275EnableClientTracingStatV2.txt [ 12349734 ]
          Hide
          Mamta A. Satoor added a comment -

          I have attached an updated review package DERBY1275EnableClientTracingDiffV1.txt As mentioned with the earlier patch, I am adding 2 client-side system properties, derby.client.traceLevel and derby.client.traceDirectory. This 2 properties will allow a user to start client tracing without having to change the actual client application.

          Summary of the patch
          1)Added an attribute for the client property prefix in Attribute.java This prefix and traceLevel or traceDirectory will define the 2 new system property names. Rather than introducing 2 new attributes with derby.client.traceLevel and derby.client.traceDirectory, I thought it will be better to just intorduce a prefix which can be used with the existing attributes for traceLevel and traceDirectory.

          2)At this point, the system property derby.client.traceLevel will only accept int values. The existing documentation at http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the user will need to use the base 10 equivalent of the hex numbers. This behavior is same as what happens inside ij. More info can be found at http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955 Specifying non-int value will result in following exception
          ERROR XJ213: The traceLevel connection property does not have a valid format for a number.

          3)I added a new junit test, ClientSideSystemProperties under tests/derbynet directory. This class relies on the decorator SystemPropertyTestSetup to set up the trace related jvm properties(derby.client.traceLevel and derby.client.traceDirectory). This property setting code happens in the suite() method. Once these properties are set, the test establishes a database connection. At the time of the test tear down, in tearDown() method, the test needs to look in the trace directory specified by derby.client.traceDirectory to see if any new files were created. If yes, then that means that the jvm properties were correctly picked by the test and tracing happened correctly. The tearDown() method then deletes the trace files and deletes the traceDirectory so that the test environment is clean.

          Now, since this test runs under security manager, the directory access part needs to happen in a privileged block. I wanted to have ClientSideSystemProperties implement java.security.PrivilegedExceptionAction and include the public synchronized final Object run() throws IOException method in ClientSideSystemProperties to write the privilege code but I kept getting compile error. The compiler was getting confused with the run() method in java.security.PrivilegedExceptionAction and the run() method in junit.framework.TestCase.
          [javac] C:\p4clients\maintest3\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\ClientSideSystemProperties.java:57: run() in org.apache.derbyTesting.functionTests.tests.derbynet.ClientSideSystemProperties cannot override run() in junit.framework.TestCase; attempting to use incompatible return type
          [javac] found : java.lang.Object
          [javac] required: junit.framework.TestResult
          [javac] public synchronized final Object run() throws IOException {
          [javac] ^
          [javac] 1 error
          [javac] Compile failed; see the compiler error output for details.
          To work around this compile time error, I decided to create a new class, DirReadAndDeletePrivledgeBlock, which extends java.security.PrivilegedExceptionAction and this new class has the directory lookup, cleanup code. An object of this class is then used by the tearDown method in , as shown below ClientSideSystemProperties
          java.security.AccessController.doPrivileged(new DirReadAndDeletePrivledgeBlock(traceDirectory));

          4)Changes in ClientBaseDataSource.java
          I have changed getTraceDirectory method to first check for the jvm properties derby.client.traceDirectory. If not found, then look for traceDirectory in the jdbc url. Similar change has been made for method getTraceLevel. Since these 2 methods now require looking at system properties, part of their code needs to be inside a privileged block. But since the methods getTraceLevel and getTraceDirectory are
          static, I can't pass an instance of their class to java.security.AccessController.doPrivileged call. To get around this, I introduced a
          new class which just implements java.security.PrivilegedExceptionAction and it's run method does the job of looking at the system properties.
          In addition, I took out some unused imports from ClientBaseDataSource.java

          5)Changes in LogWriter.java
          I had to change the PrintWriter related code in this file to run inside a privileged block. The existing code for PrintWrite is in the static method getPrintWriter. For the reasons similar to #4 above (for ClientBaseDataSource.java), I had to create a new class to do the PrintWriter code and have the LogWriter.getPrintWriter use an instance of the new class in it's java.security.AccessController.doPrivileged call.

          May be there is a better way to accomplish #4 and #5 above w/o introducing the new classes. If anyone has any ideas, please let me know. I could have created a new instance of the current class even when inside the static method but the classes LogWriter and ClientBaseDataSource are pretty big. I thought it would be better to have smaller welldefined classes to do the privileged code rather than instantiating objects of large classes.

          Items to do
          1)Since these 2 properties won't be documented in the official Derby ocumentation, I will add a wiki page for them so we don't loose track of these undocumented properties. I will mention on the page that system properties will override the same properties provided through JDBC url. I will also add that at this point, onlt int values can be specified for the system property derby.client.traceLevel.
          The existing documentation at http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the
          user will need to use the base 10 equivalent of the hext numbers.
          Disclaimer: A user can use these properties but since they are not in the official documentation, they can be changed at any point without providing any backward compatibility.

          svn stat -q is attached as DERBY1275EnableClientTracingStatV2.txt

          I have finished running the junit test suite and there were no new failures caused by this patch. The run of derbyall shows NSinSameJVM failure but from the actual diff, it doesn't look like it is related to my changes.

          Any feedback on the patch will be much appreciated.

          Show
          Mamta A. Satoor added a comment - I have attached an updated review package DERBY1275EnableClientTracingDiffV1.txt As mentioned with the earlier patch, I am adding 2 client-side system properties, derby.client.traceLevel and derby.client.traceDirectory. This 2 properties will allow a user to start client tracing without having to change the actual client application. Summary of the patch 1)Added an attribute for the client property prefix in Attribute.java This prefix and traceLevel or traceDirectory will define the 2 new system property names. Rather than introducing 2 new attributes with derby.client.traceLevel and derby.client.traceDirectory, I thought it will be better to just intorduce a prefix which can be used with the existing attributes for traceLevel and traceDirectory. 2)At this point, the system property derby.client.traceLevel will only accept int values. The existing documentation at http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the user will need to use the base 10 equivalent of the hex numbers. This behavior is same as what happens inside ij. More info can be found at http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955 Specifying non-int value will result in following exception ERROR XJ213: The traceLevel connection property does not have a valid format for a number. 3)I added a new junit test, ClientSideSystemProperties under tests/derbynet directory. This class relies on the decorator SystemPropertyTestSetup to set up the trace related jvm properties(derby.client.traceLevel and derby.client.traceDirectory). This property setting code happens in the suite() method. Once these properties are set, the test establishes a database connection. At the time of the test tear down, in tearDown() method, the test needs to look in the trace directory specified by derby.client.traceDirectory to see if any new files were created. If yes, then that means that the jvm properties were correctly picked by the test and tracing happened correctly. The tearDown() method then deletes the trace files and deletes the traceDirectory so that the test environment is clean. Now, since this test runs under security manager, the directory access part needs to happen in a privileged block. I wanted to have ClientSideSystemProperties implement java.security.PrivilegedExceptionAction and include the public synchronized final Object run() throws IOException method in ClientSideSystemProperties to write the privilege code but I kept getting compile error. The compiler was getting confused with the run() method in java.security.PrivilegedExceptionAction and the run() method in junit.framework.TestCase. [javac] C:\p4clients\maintest3\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\ClientSideSystemProperties.java:57: run() in org.apache.derbyTesting.functionTests.tests.derbynet.ClientSideSystemProperties cannot override run() in junit.framework.TestCase; attempting to use incompatible return type [javac] found : java.lang.Object [javac] required: junit.framework.TestResult [javac] public synchronized final Object run() throws IOException { [javac] ^ [javac] 1 error [javac] Compile failed; see the compiler error output for details. To work around this compile time error, I decided to create a new class, DirReadAndDeletePrivledgeBlock, which extends java.security.PrivilegedExceptionAction and this new class has the directory lookup, cleanup code. An object of this class is then used by the tearDown method in , as shown below ClientSideSystemProperties java.security.AccessController.doPrivileged(new DirReadAndDeletePrivledgeBlock(traceDirectory)); 4)Changes in ClientBaseDataSource.java I have changed getTraceDirectory method to first check for the jvm properties derby.client.traceDirectory. If not found, then look for traceDirectory in the jdbc url. Similar change has been made for method getTraceLevel. Since these 2 methods now require looking at system properties, part of their code needs to be inside a privileged block. But since the methods getTraceLevel and getTraceDirectory are static, I can't pass an instance of their class to java.security.AccessController.doPrivileged call. To get around this, I introduced a new class which just implements java.security.PrivilegedExceptionAction and it's run method does the job of looking at the system properties. In addition, I took out some unused imports from ClientBaseDataSource.java 5)Changes in LogWriter.java I had to change the PrintWriter related code in this file to run inside a privileged block. The existing code for PrintWrite is in the static method getPrintWriter. For the reasons similar to #4 above (for ClientBaseDataSource.java), I had to create a new class to do the PrintWriter code and have the LogWriter.getPrintWriter use an instance of the new class in it's java.security.AccessController.doPrivileged call. May be there is a better way to accomplish #4 and #5 above w/o introducing the new classes. If anyone has any ideas, please let me know. I could have created a new instance of the current class even when inside the static method but the classes LogWriter and ClientBaseDataSource are pretty big. I thought it would be better to have smaller welldefined classes to do the privileged code rather than instantiating objects of large classes. Items to do 1)Since these 2 properties won't be documented in the official Derby ocumentation, I will add a wiki page for them so we don't loose track of these undocumented properties. I will mention on the page that system properties will override the same properties provided through JDBC url. I will also add that at this point, onlt int values can be specified for the system property derby.client.traceLevel. The existing documentation at http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the user will need to use the base 10 equivalent of the hext numbers. Disclaimer: A user can use these properties but since they are not in the official documentation, they can be changed at any point without providing any backward compatibility. svn stat -q is attached as DERBY1275EnableClientTracingStatV2.txt I have finished running the junit test suite and there were no new failures caused by this patch. The run of derbyall shows NSinSameJVM failure but from the actual diff, it doesn't look like it is related to my changes. Any feedback on the patch will be much appreciated.
          Hide
          Daniel John Debrunner added a comment -

          The policy file already grants permission to any property when running using the classes folder.

          grant codeBase "$

          {derbyTesting.codeclasses}

          " {
          // Access all properties using System.getProperties
          permission java.util.PropertyPermission "*", "read, write";

          So for this change the policy file should not need to be altered.

          Show
          Daniel John Debrunner added a comment - The policy file already grants permission to any property when running using the classes folder. grant codeBase "$ {derbyTesting.codeclasses} " { // Access all properties using System.getProperties permission java.util.PropertyPermission "*", "read, write"; So for this change the policy file should not need to be altered.
          Hide
          Mamta A. Satoor added a comment -

          Dan(on Derby developer list) pointed me to following link about passing system properties to a junit test
          http://wiki.apache.org/db-derby/KillDerbyTestHarness#head-7c93c8d40525f1a79304ac980a098edf08bf4105
          First FAQ in the list.

          Show
          Mamta A. Satoor added a comment - Dan(on Derby developer list) pointed me to following link about passing system properties to a junit test http://wiki.apache.org/db-derby/KillDerbyTestHarness#head-7c93c8d40525f1a79304ac980a098edf08bf4105 First FAQ in the list.
          Hide
          Mamta A. Satoor added a comment -

          Dan, I haven't tried running junit tests with jar files. The junit tests probably won't run into SecurityException error for my changes because of already granted permission to derbyclient.jar in the testing policy file.

          I ran junit tests with plain classes and that is why I probably ran into SecurityException (since the permissions are granted to the jar file which is not being used when running with just classes) Does this interpretation sound right? Having said that, I wonder why (if there are any such tests) junit tests today don't run into SecurityException for exeisting properties when run with classes if those properties haven't been granted at all code level.

          Show
          Mamta A. Satoor added a comment - Dan, I haven't tried running junit tests with jar files. The junit tests probably won't run into SecurityException error for my changes because of already granted permission to derbyclient.jar in the testing policy file. I ran junit tests with plain classes and that is why I probably ran into SecurityException (since the permissions are granted to the jar file which is not being used when running with just classes) Does this interpretation sound right? Having said that, I wonder why (if there are any such tests) junit tests today don't run into SecurityException for exeisting properties when run with classes if those properties haven't been granted at all code level.
          Hide
          Daniel John Debrunner added a comment -

          I think the fact you need to grant permission to read these new properties to all code indicates a bug. You should be able to grant permission just to derbyclient.jar, and the testing policy file already covers reading these properties.

          Show
          Daniel John Debrunner added a comment - I think the fact you need to grant permission to read these new properties to all code indicates a bug. You should be able to grant permission just to derbyclient.jar, and the testing policy file already covers reading these properties.
          Hide
          Mamta A. Satoor added a comment -

          Forgot to add that I have fired the derby suite and they have been running with no errors so far. Will post another comment after the suite finishes.

          Show
          Mamta A. Satoor added a comment - Forgot to add that I have fired the derby suite and they have been running with no errors so far. Will post another comment after the suite finishes.
          Hide
          Mamta A. Satoor added a comment -

          I have attached a small review package(DERBY1275EnableClientTracingDiffV1.txt) for this Jira entry. I have taken Kathey's suggested way of approaching the issue which is to introduce 2 system properties, derby.client.traceLevel and derby.client.traceDirectory. These 2 properties will enable a customer to start client tracing without having to change the actual client application. The discussion on the Jira has talked about keeping these properties as unsupported and putting them on a wiki page rather than the official documentation. If we agree on that, then I can go ahead and put something on a wiki page. Do we already have a wiki page for unsupported Derby stuff? If yes, then I can go ahead and use that same wiki page. I will mention on that page that traceLevel and traceDirectory values specified through JVM system property will overwrite what is passed through the jdbc url.

          Now to go over the changes that went into the patch
          1)Added an attribute for the client property prefix in Attribute.java This prefix and traceLevel or traceDirectory will define the 2 new system property names. Rather than introducing 2 new attributes with derby.client.traceLevel and derby.client.traceDirectory, I thought it will be better to just intorduce a prefix which can be used with the existing attributes for traceLevel and traceDirectory.
          2)At this point, the system property derby.client.traceLevel will only accept int values. The existing documentation at
          http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the user will need to use the base 10 equivalent of the hext numbers. Specifying non-int value will result in following exception
          ERROR XJ213: The traceLevel connection property does not have a valid format for a number.
          This behavior is same as what happens inside ij. More info can be found at
          http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955
          3)The junit test framework requires that I put these 2 new properties in functionTests/util/derby_tests.policy so that properties can be read without running SecurityException.
          4)I manually tested my changes but don't know how to add a test in the test suite so I can pass these new system properties. Would appreciate if anyone has some info on this.

          Show
          Mamta A. Satoor added a comment - I have attached a small review package(DERBY1275EnableClientTracingDiffV1.txt) for this Jira entry. I have taken Kathey's suggested way of approaching the issue which is to introduce 2 system properties, derby.client.traceLevel and derby.client.traceDirectory. These 2 properties will enable a customer to start client tracing without having to change the actual client application. The discussion on the Jira has talked about keeping these properties as unsupported and putting them on a wiki page rather than the official documentation. If we agree on that, then I can go ahead and put something on a wiki page. Do we already have a wiki page for unsupported Derby stuff? If yes, then I can go ahead and use that same wiki page. I will mention on that page that traceLevel and traceDirectory values specified through JVM system property will overwrite what is passed through the jdbc url. Now to go over the changes that went into the patch 1)Added an attribute for the client property prefix in Attribute.java This prefix and traceLevel or traceDirectory will define the 2 new system property names. Rather than introducing 2 new attributes with derby.client.traceLevel and derby.client.traceDirectory, I thought it will be better to just intorduce a prefix which can be used with the existing attributes for traceLevel and traceDirectory. 2)At this point, the system property derby.client.traceLevel will only accept int values. The existing documentation at http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html talks about symbolic values or the hex values but the new system property derby.client.traceLevel will not accept any of these 2 documented ways. Instead, the user will need to use the base 10 equivalent of the hext numbers. Specifying non-int value will result in following exception ERROR XJ213: The traceLevel connection property does not have a valid format for a number. This behavior is same as what happens inside ij. More info can be found at http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955 3)The junit test framework requires that I put these 2 new properties in functionTests/util/derby_tests.policy so that properties can be read without running SecurityException. 4)I manually tested my changes but don't know how to add a test in the test suite so I can pass these new system properties. Would appreciate if anyone has some info on this.
          Mamta A. Satoor made changes -
          Attachment DERBY1275EnableClientTracingDiffV1.txt [ 12349202 ]
          Attachment DERBY1275EnableClientTracingStatV1.txt [ 12349203 ]
          Mamta A. Satoor made changes -
          Assignee Mamta A. Satoor [ mamtas ]
          Rick Hillegas made changes -
          Fix Version/s 10.2.3.0 [ 12312215 ]
          Fix Version/s 10.2.2.0 [ 12312027 ]
          Hide
          Rick Hillegas added a comment -

          Move to 10.2.3.0.

          Show
          Rick Hillegas added a comment - Move to 10.2.3.0.
          Hide
          Mike Matrigali added a comment -

          I think as a short fix you should just add the 2 system properties that kathey proposes. This seems like a reasonable short term fix to allow debugging at a client site without having to have access to
          their source code and needing to recompile their source to enable some debug tracing.

          Show
          Mike Matrigali added a comment - I think as a short fix you should just add the 2 system properties that kathey proposes. This seems like a reasonable short term fix to allow debugging at a client site without having to have access to their source code and needing to recompile their source to enable some debug tracing.
          Hide
          Mamta A. Satoor added a comment -

          There have been discussion on this jira entry for 2 possible solutions.
          1)One is to implement the way the server does, ie using something equivalent to derby.home on the client side.
          2)The other is to explore JMX.

          I don't have knowledge about JMX but seems like JMX could be used not just for the properties associated with this Jira entry but also for the properties in general supported by Derby. If that is the case, then may be it should be taken on as a feature by itself and for now implement this Jira entry in a fashion similar to what Derby server already does. Any thoughts on this, or other proposed solutions?

          Show
          Mamta A. Satoor added a comment - There have been discussion on this jira entry for 2 possible solutions. 1)One is to implement the way the server does, ie using something equivalent to derby.home on the client side. 2)The other is to explore JMX. I don't have knowledge about JMX but seems like JMX could be used not just for the properties associated with this Jira entry but also for the properties in general supported by Derby. If that is the case, then may be it should be taken on as a feature by itself and for now implement this Jira entry in a fashion similar to what Derby server already does. Any thoughts on this, or other proposed solutions?
          Rick Hillegas made changes -
          Fix Version/s 10.2.2.0 [ 12312027 ]
          Fix Version/s 10.2.1.0 [ 11187 ]
          Hide
          Rick Hillegas added a comment -

          Moving to 10.2.2.0.

          Show
          Rick Hillegas added a comment - Moving to 10.2.2.0.
          Rick Hillegas made changes -
          Urgency Normal
          Kathey Marsden made changes -
          Field Original Value New Value
          Fix Version/s 10.2.0.0 [ 11187 ]
          Hide
          Kathey Marsden added a comment -

          Adding this as a high value fix candidate to the 10.2 list so that it might be picked up for 10.2. The original crisis that prompted me to think I might do this ended so I didn't pursue it myself. There was a suggestion that JMX might resolve the issue but I think that would require additional jar distribution and also I think won't be available for 10.2, so it would be good to have some way to to enable tracing at end user sites without asking the application writers to send out a new build. As Knut suggested it can just be mentioned on a wiki page and not the official documentation so we don't have to stick with the quick fix moving forward.

          Show
          Kathey Marsden added a comment - Adding this as a high value fix candidate to the 10.2 list so that it might be picked up for 10.2. The original crisis that prompted me to think I might do this ended so I didn't pursue it myself. There was a suggestion that JMX might resolve the issue but I think that would require additional jar distribution and also I think won't be available for 10.2, so it would be good to have some way to to enable tracing at end user sites without asking the application writers to send out a new build. As Knut suggested it can just be mentioned on a wiki page and not the official documentation so we don't have to stick with the quick fix moving forward.
          Hide
          Knut Anders Hatlen added a comment -

          Hi Kathey, I think your approach sounds reasonable. It is definitely good to have some simple way (documented or undocumented) to enable client-side tracing. By not documenting it, we don't commit to support it in case we find a better way in the future. However, I think it's a good idea that we maintain a list of such undocumented features somewhere. Otherwise, I fear that they will be forgotten and just make the code less maintainable. What about creating a wiki page with undocumented properties/features (clearly labelled as unsupported, of course)?

          Show
          Knut Anders Hatlen added a comment - Hi Kathey, I think your approach sounds reasonable. It is definitely good to have some simple way (documented or undocumented) to enable client-side tracing. By not documenting it, we don't commit to support it in case we find a better way in the future. However, I think it's a good idea that we maintain a list of such undocumented features somewhere. Otherwise, I fear that they will be forgotten and just make the code less maintainable. What about creating a wiki page with undocumented properties/features (clearly labelled as unsupported, of course)?
          Hide
          Kathey Marsden added a comment -

          Would there be any objections if for now I just added recognition of these two system properties:

          derby.client.traceLevel - set global traceLevel
          derby.client.traceDirectory - set global traceDirectory

          and checked that in without documenting, so they are a completely unstable interface.

          Then once a decision has been made about how to handle this sort of global setting in different classloader contexts and with autoloading we can do it the right way.

          It is just too hard to not be able to enable tracing when diagnosing problems without asking users to change their apps.

          Show
          Kathey Marsden added a comment - Would there be any objections if for now I just added recognition of these two system properties: derby.client.traceLevel - set global traceLevel derby.client.traceDirectory - set global traceDirectory and checked that in without documenting, so they are a completely unstable interface. Then once a decision has been made about how to handle this sort of global setting in different classloader contexts and with autoloading we can do it the right way. It is just too hard to not be able to enable tracing when diagnosing problems without asking users to change their apps.
          Hide
          Kathey Marsden added a comment -

          I was wondering if anyone had any thoughts on how to implement this improvement to
          provide a way to enable client tracing without changing the application

          Not being able to turn on tracing in a deployed application without application code changes is a serious supportability issue because unless the application has a mechanism to configure settings like traceDirectory and traceLevel, the application itself my have to be rebuilt to enable client tracing. Even when such a mechanism is provided it takes someone with knowledge of the application to turn it on, again a supportability issue.

          All I can think of is supporting System properties like derby.client.traceLevel. We also could mimic our server side mechanism and have a System property derby.client.home that points to a directory where a file derby.client.properties can live and the trace files can go by default. The System property mechanism raises a red flag for me because of class loader issues like we have for derby.system.home. But maybe it is ok because of the diagnostic nature.

          I ask this question because I find myself in need to put this into a debug build to send to a user and figure I might as well head down the correct path toward an ultimate solution.

          Thoughts?

          Show
          Kathey Marsden added a comment - I was wondering if anyone had any thoughts on how to implement this improvement to provide a way to enable client tracing without changing the application Not being able to turn on tracing in a deployed application without application code changes is a serious supportability issue because unless the application has a mechanism to configure settings like traceDirectory and traceLevel, the application itself my have to be rebuilt to enable client tracing. Even when such a mechanism is provided it takes someone with knowledge of the application to turn it on, again a supportability issue. All I can think of is supporting System properties like derby.client.traceLevel. We also could mimic our server side mechanism and have a System property derby.client.home that points to a directory where a file derby.client.properties can live and the trace files can go by default. The System property mechanism raises a red flag for me because of class loader issues like we have for derby.system.home. But maybe it is ok because of the diagnostic nature. I ask this question because I find myself in need to put this into a debug build to send to a user and figure I might as well head down the correct path toward an ultimate solution. Thoughts?
          Kathey Marsden created issue -

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development