[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510714 ] Kathey Marsden commented on DERBY-1275: --- I linked the issue that made the permissions optional. It is fine for this issue to be closed. > 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 >Assignee: Mamta A. Satoor >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510701 ] Myrna van Lunteren commented on DERBY-1275: --- Kathey, did you make the permissions optional or not? Should this bug be closed? > 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 >Assignee: Mamta A. Satoor >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500898 ] Kathey Marsden commented on DERBY-1275: --- 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. > 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 >Assignee: Mamta A. Satoor >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478616 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478610 ] Laura Stewart commented on DERBY-1275: -- Can you help me understand what, if anything, needs to be documented in the Derby books about this issue? > 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.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471030 ] Mamta A. Satoor commented on DERBY-1275: 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"; > 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.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471007 ] Daniel John Debrunner commented on DERBY-1275: -- 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? > 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.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470985 ] Knut Anders Hatlen commented on DERBY-1275: --- 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 > 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.3.0.0 > > Attachments: DERBY1275EnableClientTracingDiffV1.txt, > DERBY1275EnableClientTracingDiffV2.txt, > DERBY1275EnableClientTracingDiffV3.txt, > DERBY1275EnableClientTracingDiffV4.txt, > DERBY1275EnableClientTracingDiffV5.txt, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, > DERBY1275EnableClientTracingStatV3.txt, > DERBY1275EnableClientTracingStatV4.txt, DERBY1275EnableClientTracingStatV5.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469528
]
Mamta A. Satoor commented on DERBY-1275:
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.
> 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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[
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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469447
]
Mamta A. Satoor commented on DERBY-1275:
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);
}
> 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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469264 ] Daniel John Debrunner commented on DERBY-1275: -- 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. > 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, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, DERBY1275EnableClientTracingStatV3.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469255 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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, > DERBY1275EnableClientTracingStatV1.txt, > DERBY1275EnableClientTracingStatV2.txt, DERBY1275EnableClientTracingStatV3.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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468323
]
Daniel John Debrunner commented on DERBY-1275:
--
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?
> 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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ 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.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465905
]
Daniel John Debrunner commented on DERBY-1275:
--
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.
> 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,
> DERBY1275EnableClientTracingStatV1.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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465898 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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, > DERBY1275EnableClientTracingStatV1.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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465892 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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, > DERBY1275EnableClientTracingStatV1.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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465876 ] Daniel John Debrunner commented on DERBY-1275: -- 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. > 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, > DERBY1275EnableClientTracingStatV1.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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465853 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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, > DERBY1275EnableClientTracingStatV1.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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Mamta A. Satoor (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465845 ] Mamta A. Satoor commented on DERBY-1275: Do we already have a wiki page for unsupported Derby stuff? Given this is open source it's no such much "unsupported" as just "undocumented", though of course if it is on the wiki it is documented in some form that users can find. :-) 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. See http://wiki.apache.org/db-derby/KillDerbyTestHarness#head-7c93c8d40525f1a79304ac980a098edf08bf4105 First FAQ in the list. Dan.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465845 ] Mamta A. Satoor commented on DERBY-1275: 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. > 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, > DERBY1275EnableClientTracingStatV1.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. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12442076 ] Mamta A. Satoor commented on DERBY-1275: 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? > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Issue Type: Improvement > Components: Network Client >Affects Versions: 10.2.1.6, 10.1.3.1 >Reporter: Kathey Marsden >Priority: Minor > Fix For: 10.2.2.0 > > > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
IMHO, this is exactly the kind of thing JMX is suited for. David Kathey Marsden wrote: Sanket Sharma wrote: This sounds like a perfect case for JMX soultion and can be added to list of requirements on derby Wiki. Tracing options (enable/disable) The requirement for this is that we have something that can be turned on quickly by the user when talking to tech support so we can easily get the traces produced and back for analysis without the need to download any additional software or libraries. I am sure it would be much more helpful if I knew something about JMX, but given those requirements, would JMX work for this? Kathey
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Sanket Sharma wrote: This sounds like a perfect case for JMX soultion and can be added to list of requirements on derby Wiki. Tracing options (enable/disable) The requirement for this is that we have something that can be turned on quickly by the user when talking to tech support so we can easily get the traces produced and back for analysis without the need to download any additional software or libraries. I am sure it would be much more helpful if I knew something about JMX, but given those requirements, would JMX work for this? Kathey
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
This sounds like a perfect case for JMX soultion and can be added to list of requirements on derby Wiki. Tracing options (enable/disable) and perhaps the file name can be exposed as JMX operations. While debugging the application the developers can start derby in JMX mode and enable/disable tracing via JConsole. Comments welcome. Regards, Sanket On 6/23/06, Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ] Kathey Marsden commented on DERBY-1275: --- 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? > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.2.3 > Reporter: Kathey Marsden > Priority: Minor > > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417481 ] Kathey Marsden commented on DERBY-1275: --- 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 I also think, it is good to have some properties to enable client side tracing. This will help users to enable tracing without having to change their application programmatically. Thanks, Sunitha.
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417497 ] Knut Anders Hatlen commented on DERBY-1275: --- 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)? > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.2.3 > Reporter: Kathey Marsden > Priority: Minor > > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417481 ] Kathey Marsden commented on DERBY-1275: --- 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. > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.2.3 > Reporter: Kathey Marsden > Priority: Minor > > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ] Kathey Marsden commented on DERBY-1275: --- 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? > Provide a way to enable client tracing without changing the application > --- > > Key: DERBY-1275 > URL: http://issues.apache.org/jira/browse/DERBY-1275 > Project: Derby > Type: Improvement > Components: Network Client > Versions: 10.2.0.0, 10.1.2.3 > Reporter: Kathey Marsden > Priority: Minor > > 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. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
