db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1275) Provide a way to enable client tracing without changing the application
Date Sat, 27 Jan 2007 16:51:49 GMT

     [ https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mamta A. Satoor updated DERBY-1275:

    Attachment: DERBY1275EnableClientTracingStatV2.txt

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

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.

> Provide a way to enable client tracing without changing the application
> -----------------------------------------------------------------------
>                 Key: DERBY-1275
>                 URL: https://issues.apache.org/jira/browse/DERBY-1275
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Client
>    Affects Versions:,
>            Reporter: Kathey Marsden
>         Assigned To: Mamta A. Satoor
>            Priority: Minor
>             Fix For:
>         Attachments: DERBY1275EnableClientTracingDiffV1.txt, DERBY1275EnableClientTracingDiffV2.txt,
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.

View raw message